DEV Community: Arya Hegiste

Visualizing a Mixed-Entity DynamoDB Table: What Schema Inference Reveals—and What It Misses

Arya Hegiste — Sat, 10 Oct 2026 18:05:27 +0000

Introduction

One of the most interesting aspects of Amazon DynamoDB is that a table does not need to represent a single business entity.

In a relational database, we might create separate tables for users, orders, and products, with foreign keys connecting related records. DynamoDB supports a different approach: multiple entity types can coexist in a single table, using carefully designed partition keys, sort keys, and secondary indexes to support application access patterns.

This is commonly called single-table design.

However, single-table design introduces an interesting challenge: how do we understand the logical structure of a table when the physical database does not enforce a complete schema for every item?

To explore this, I used the Schema Visualizer in Tables by Serverless Creed to examine two controlled DynamoDB datasets:

A 70-item dataset containing User, Order, and Product records.
A smaller three-item dataset with explicit EntityType attributes.

The results revealed an important distinction between physical key patterns, logical entity boundaries, and inferred schemas.

In this article, I'll examine the underlying DynamoDB design, compare the visualizer's findings with the known datasets, and discuss what engineers should verify before trusting an inferred data model.

1. Understanding the challenge of mixed-entity tables

DynamoDB is a NoSQL database that supports flexible item attributes. Within a table, different items can contain different non-key attributes.

For example, consider an application containing three logical entities:

Entity	Example attributes
User	Name, Email, Active
Order	OrderId, Amount, Status
Product	ProductName, Price, Stock

These entities can be represented in one DynamoDB table using a composite primary key.

A partition key determines the logical partition-key value associated with an item, while the sort key distinguishes items within that partition-key value and supports ordered access.

A possible design is:

PK	SK	Logical entity
`USER#001`	`PROFILE`	User
`USER#001`	`ORDER#001`	Order
`PRODUCT#001`	`META`	Product

Notice that the User and Order records share the same partition key.

This is intentional.

If an application frequently needs a user's profile and orders, storing related items under the same partition key can support efficient access through DynamoDB's Query operation.

For example:

response = dynamodb.query(
    TableName="TC-OPT-002-Blog",
    KeyConditionExpression="PK = :pk AND begins_with(SK, :prefix)",
    ExpressionAttributeValues={
        ":pk": {"S": "USER#001"},
        ":prefix": {"S": "ORDER#"}
    }
)

This illustrative Boto3 low-level client query retrieves order items under a specific user partition-key value.

The important design decision is that the partition key represents an access grouping, not necessarily an entity type.

A single partition-key pattern can contain several logical entities.

That distinction becomes particularly important when software attempts to infer the schema automatically.

2. Experiment One: Analyzing a 70-item mixed-entity table

My first experiment used the DynamoDB table:

TC-OPT-002-Test

The dataset contained 70 items representing User profiles, Orders, and Products.

The table used:

Composite primary key: PK and SK
On-demand capacity mode
One Global Secondary Index, GSI1
AWS Region: ap-south-1

The known fixture contained:

Record type	Items	Key structure
User profiles	20	`USER#<userId>` / `PROFILE`
Orders	40	`USER#<userId>` / `ORDER#<orderId>`
Products	10	`PRODUCT#<productId>` / `META`
Total	70

Verifying an application access pattern

Before examining the inferred schema, I verified that the table supported a practical query.

Using USER#001 as the partition-key value and ORDER# as the sort-key prefix, the query returned two matching order items.

This demonstrated an important advantage of the design: related orders could be retrieved using a key condition rather than scanning the entire table.

Figure 1 — Querying orders under a user partition key

A DynamoDB Query with a partition-key equality condition and sort-key prefix can target a specific access pattern. By contrast, a table-wide Scan reads through the table and is generally less suitable for frequently executed, selective application requests.

This is why DynamoDB data modeling begins with access patterns rather than simply copying a relational entity diagram.

3. What the Schema Visualizer inferred

After verifying the dataset, I opened the Schema Visualizer.

The results were interesting.

Although the known fixture contained three logical entity types, the visualizer reported:

Metric	Observed result
Inferred entities	2
Relationships	0
Global Secondary Indexes	1
Attributes	19
Displayed confidence	95%

The inferred entity groups were:

User and Product.

Order was not represented as a separate inferred entity.

Figure 2 — Schema Visualizer showing two inferred entities

Why were Orders grouped with Users?

The Key Structure view provided a useful explanation.

The visualizer identified 60 items associated with the USER#<userId> partition-key pattern:

40 items with ORDER#<orderId> sort keys
20 items with PROFILE sort keys

The remaining 10 items followed the PRODUCT#<productId> partition-key pattern.

Figure 3 — Key structure showing 60 User-group items and 10 Product items

This illustrates the central modeling problem.

From the application's perspective, User and Order are different business entities.

From the physical key perspective, both are stored under the same USER# partition-key pattern.

The visualizer's output was consistent with grouping those items by their shared partition-key structure.

However, the screenshot does not establish the exact internal inference algorithm. We cannot conclude that partition-key prefixes were the only factor responsible for the grouping.

The engineering lesson is broader:

A schema inferred from observed keys is a hypothesis about the logical model—not a definitive description of the application's business entities.

4. Examining the Global Secondary Index

The original table also contained one active GSI:

Index: GSI1
Partition key: GSI1PK
Sort key: GSI1SK
Projection: ALL

The Schema Visualizer's Access Paths view showed that 16 items in the inferred User group participated in this index, representing approximately 27% of that 60-item group.

Figure 4 — GSI access path and observed index coverage

This is a useful example of a sparse index.

In DynamoDB, an item appears in a GSI only when the required index key attributes are present. A table can therefore contain many items while only a subset participates in a particular GSI.

Sparse indexes are useful when an application needs an alternative access pattern for selected records without indexing every item.

For example, an application might populate GSI keys only for orders requiring processing or records associated with a particular lookup pattern.

The screenshot establishes that only a subset of the observed items participated in GSI1; it does not establish why those particular records were indexed.

Another important consideration is that a GSI introduces additional storage and write costs. Indexes should therefore be designed around demonstrated access requirements rather than created for every potentially useful attribute.

5. Experiment Two: Can explicit entity types clarify the model?

The original experiment raised a useful question:

What happens when the logical entity type is explicitly recorded as an item attribute?

To investigate, I created a second disposable table:

TC-OPT-002-Blog

This experiment was performed using Tables version 3.3.37 in ap-south-1.

The table used the same PK and SK key names, but contained only three items and no GSI.

User record

{
  "PK": "USER#001",
  "SK": "PROFILE",
  "EntityType": "USER",
  "Name": "Test User 1",
  "Email": "user1@example.com"
}

Order record

{
  "PK": "USER#001",
  "SK": "ORDER#001",
  "EntityType": "ORDER",
  "OrderId": "ORDER#001",
  "Amount": 1499,
  "Status": "PLACED"
}

Product record

{
  "PK": "PRODUCT#001",
  "SK": "META",
  "EntityType": "PRODUCT",
  "ProductName": "Wireless Keyboard",
  "Price": 1299,
  "Stock": 25
}

The important property is that User and Order still share the same partition-key value, USER#001.

The distinction is expressed through both the sort-key pattern and the explicit EntityType attribute.

Figure 5 — Three-item fixture showing PK, SK, and EntityType

6. Comparing the second inference result

When I opened the Schema Visualizer for the smaller fixture, the output was different.

This time, Tables inferred all three logical entities:

Order, Product, and User.

The results were:

Metric	Observed result
Inferred entities	3
Relationships	0
GSIs	0
Attributes	11
Displayed confidence	91%

Figure 6 — Three inferred entities in the smaller fixture

The Key Structure view provided additional detail.

Inferred entity	PK pattern	SK pattern
Order	`USER#<userId>`	`ORDER#<orderId>`
User	`USER#<userId>`	`PROFILE`
Product	`PRODUCT#<productId>`	`META`

Figure 7 — Distinct User and Order groups sharing a PK pattern

This result is especially interesting because the partition-key pattern alone still cannot distinguish User from Order.

The two records share the same USER# pattern, but differ in their sort keys and explicit entity types.

The second fixture therefore demonstrates that the visualizer can represent distinct logical entities sharing a partition-key pattern.

Did `EntityType` cause the difference?

Not necessarily.

The experiments differed in multiple ways:

Dataset size: 70 items versus 3
Attribute distribution
Number of GSIs
Distribution of sort-key patterns
Explicit entity-type values in the smaller fixture

Because these variables were not controlled independently, the results do not prove that adding EntityType alone changed the inference.

A stronger causal experiment would compare identical fixtures with and without the EntityType attribute while holding the other variables constant.

For this article, the supported conclusion is narrower: the smaller fixture, which included explicit entity types, produced three inferred groups, while the original larger fixture produced two.

7. Verifying entity types independently of schema inference

A visualizer is useful for understanding the model, but an engineer should also verify the underlying records.

I applied two filters in the table's data workspace.

First:

EntityType = ORDER

The result was the order item:

PK: USER#001
SK: ORDER#001
EntityType: ORDER

Figure 8 — Filtering for Order items

Then:

EntityType = USER

The result was the profile item:

PK: USER#001
SK: PROFILE
EntityType: USER

Figure 9 — Filtering for User items

Both filters scanned three items and returned one matching item.

This confirms that the logical entity types can be distinguished directly from their stored attributes, even when they share a partition-key value.

An important performance consideration

The verification used a Scan with an attribute filter.

This is acceptable for inspecting a three-item test fixture, but it should not automatically become the production access strategy.

DynamoDB filter expressions are applied after items have been read. They do not reduce the read capacity consumed by the underlying scan or query.

For application workloads, a better approach is often to use the primary key and sort-key conditions directly.

For example:

PK = USER#001
SK begins_with ORDER#

This retrieves orders associated with a specific user without scanning unrelated partition-key values.

The EntityType attribute remains valuable for semantic clarity, application validation, and analytical interpretation, but it is not automatically an efficient query key.

8. Why schema inference requires engineering judgment

Comparing the two experiments reveals several limitations engineers should understand.

Inference depends on observed data

A DynamoDB table may contain optional attributes, rare entity types, and records that appear only in certain application states.

If an inference process examines only a subset of the data, uncommon patterns may be absent from the sample.

Therefore, the inferred model should not be treated as a guaranteed complete representation of every item in the table.

Confidence is not a completeness guarantee

The original visualizer displayed 95% confidence while identifying two entities.

The smaller fixture displayed 91% confidence while identifying three.

These percentages should not be interpreted as a verified probability that the application model is correct or complete. Without the internal confidence calculation, their precise statistical meaning is unknown.

A higher displayed confidence does not necessarily mean more business entities have been identified.

Relationships are not always explicit

Both experiments reported zero inferred relationships.

That does not prove that the application has no logical relationships.

In single-table design, relationships can be represented through shared partition keys, sort-key conventions, and application-level access patterns rather than foreign-key constraints.

The User–Order association in this experiment is an example.

An inferred model is not the same as a deployed schema

In the original test, I also opened the inferred design in the Single-Table Modeler, where four access patterns were reported as valid.

This was useful for reviewing whether the inferred design could represent the configured access patterns.

However, model validation should not be confused with independent proof that every production query will perform efficiently or that every possible item shape has been discovered.

The visualizer and modeler are engineering aids. They do not replace workload testing and independent verification.

9. Practical recommendations for DynamoDB engineers

Based on these experiments, I would apply the following principles when working with mixed-entity DynamoDB tables.

Design around access patterns. Decide which queries the application needs before choosing partition keys, sort keys, and GSIs.

Make logical entity types explicit where useful. An attribute such as EntityType improves clarity, validation, and troubleshooting, especially when different entities share key prefixes.

Use sort-key conventions consistently. Patterns such as PROFILE, ORDER#<orderId>, and META help express the intended item structure.

Treat inferred schemas as working models. Compare them with known fixtures, application code, and real query requirements.

Inspect sparse GSI participation. A GSI may intentionally contain only selected records. Verify that its coverage matches the intended access pattern.

Separate semantic filtering from efficient retrieval. An attribute filter may distinguish entity types, but a key condition is generally preferable for selective access.

Verify the data independently. A diagram can reveal patterns, but direct item inspection and DynamoDB queries establish what is actually stored.

10. Conclusion

DynamoDB single-table design allows multiple business entities to share a physical table and even the same partition-key pattern.

That flexibility is powerful, but it also makes schema discovery more complicated than simply reading a table definition.

In my first experiment, the Schema Visualizer examined a 70-item mixed-entity fixture and inferred two groups, even though the known application dataset contained User, Order, and Product records.

In the second experiment, a three-item fixture with explicit EntityType attributes produced three inferred entities, including separate User and Order groups sharing the same partition-key pattern.

The comparison highlights an important principle:

A DynamoDB key structure tells us how data is organized for access. It does not always tell us where one business entity ends and another begins.

Tools such as the Schema Visualizer can make key patterns, inferred entities, and secondary-index access paths easier to understand. But their results become most valuable when engineers compare those inferences with the known data model and the application's actual access requirements.

The goal is not merely to generate a diagram.

It is to understand whether the inferred structure accurately represents the system we intend to build.

Technical environment

Component	Details
Application	Tables by Serverless Creed
Confirmed application version	3.3.37 (second experiment)
Database	Amazon DynamoDB
AWS Region	`ap-south-1`
Original dataset	70 items, 1 GSI
Follow-up dataset	3 items, 0 GSIs
Primary key	`PK` (String), `SK` (String)
Verification	Tables queries, scans, filters, and Schema Visualizer

Note: The original 70-item experiment's application version was not independently recorded.

Want to give it a try: https://tables.serverlesscreed.com/

Import CSV Data into DynamoDB with Tables: Validate, Fix, and Retry Invalid Rows

Arya Hegiste — Wed, 07 Oct 2026 02:16:06 +0000

Importing CSV data into DynamoDB involves more than moving rows from a file into a table. Before writing anything, it is important to understand how source columns map to DynamoDB attributes, how types are inferred, and what happens when a record is missing a required key.

In this walkthrough, I use Tables by Serverless Creed to import CSV data into DynamoDB and examine how the workflow handles valid records, type inference, and rows with missing partition or sort keys.

We’ll specifically look at:

Importing a large CSV fixture
Reviewing type inference
Testing records with missing DynamoDB keys
Confirming invalid input is blocked before import
Correcting the input and retrying
Verifying the recovered records in DynamoDB The goal is not simply to see an “import completed” message. We want to verify what actually reached the table and understand how to recover when validation fails.

1. Prepare the import fixture
For this exercise, I used the disposable DynamoDB table:

TC-IMP-002-Test

The table uses a composite key consisting of a partition key and sort key.

The main CSV fixture contained 1,000 source rows designed to exercise several import behaviors:

Valid records
Duplicate-key records
Records missing required keys
A value designed to inspect type inference

After the initial import, the DynamoDB table contained:

961 items

This stored-item count should not automatically be interpreted as “961 accepted and 39 rejected.”

Duplicate DynamoDB keys can overwrite an existing item rather than increase the number of unique items in the table. Also, because the original import completion dialog was not retained, I do not have direct evidence for the exact accepted, rejected, and duplicate counters from that run.

For that reason, I use the resulting table state as an observation rather than reconstructing import-summary numbers that were not captured.

Figure 1 — DynamoDB table after the initial CSV import

2. Inspect type inference instead of assuming a validation error
One record in the fixture was intentionally given a value that looked incompatible with a numeric field:

PK: INVALID#001
Value: not-a-number

A reasonable assumption might be that the importer would reject the record because not-a-number is not numeric.

That is not what happened in this test.

After the import, I inspected INVALID#001 in Tables. The value had been imported as a DynamoDB String.

In other words, the importer did not treat this value as a malformed number. Its type inference allowed the value to be represented as text.

Figure 2 — not-a-number imported as a String through type inference

This is an important distinction when investigating an import.

A value that appears invalid according to an expected application schema is not necessarily invalid according to DynamoDB's data model or the importer's inferred type.

Required key violations, however, are different.

3. Create a controlled missing-key test
To test a clear validation failure, I used a smaller CSV containing three rows:

PK,SK,Name,Value
TEST#001,PROFILE,Valid Control,1
,PROFILE,Missing PK,2
TEST#003,,Missing SK,3

The first record contains both required keys.

The second record is missing the partition key (PK).

The third record is missing the sort key (SK).

This gives us one valid control record and two deliberately invalid records.

When this file was loaded into the import workflow, the preview made the missing key values visible before the import was allowed to proceed.

Figure 3 — Import preview containing missing PK and SK values

4. Block invalid rows before writing
Tables identified the key problem during preview validation.

The interface reported:

2 preview rows are missing a required key value. Fix the source data or mapping before importing.

The Start import action was disabled.

This is an important safety behavior because DynamoDB requires the complete primary key for an item. Rather than beginning the import and discovering the key problem after writes had started, the workflow blocked this controlled import during validation.

The screen also showed the target table and import configuration, making it possible to confirm where the operation would write before proceeding.

Figure 4 — Import blocked because two rows are missing required key values

At this point, the correct recovery was not to bypass the validation. The source data or mapping needed to be corrected.

5. Correct the source and retry
I corrected the three-row CSV so that every record had both required key values:

PK,SK,Name,Value
TEST#001,PROFILE,Valid Control,1
TEST#002,PROFILE,Fixed Missing PK,2
TEST#003,PROFILE,Fixed Missing SK,3

After loading the corrected input, the preview changed to:

Preview validation passed. The streaming import is ready to run.

The previously blocked import could now proceed.

Figure 5 — Corrected input passes validation and is ready for retry

This creates a clear recovery sequence:

Missing required keys
        ↓
Preview validation fails
        ↓
Import blocked
        ↓
Correct source/mapping
        ↓
Preview validation passes
        ↓
Retry import

No special workaround was needed. The recovery consisted of correcting the data so it satisfied the target table's key requirements and then rerunning the normal import workflow.

6. Verify the recovered data in DynamoDB
An import completion message is useful, but I also wanted to verify that the corrected data actually existed in DynamoDB.

After the retry, I read back:

PK: TEST#002
SK: PROFILE

The resulting item contained:

Name: Fixed Missing PK
Value: 2

The table count had also increased from:

to:

which is consistent with the three corrected test records being added as unique items.

Figure 6 — Corrected TEST#002 item read back after the successful retry

This final read-back is useful because it verifies the resulting table state rather than relying solely on the import UI.

Type inference and key validation solve different problems
One of the more useful lessons from this exercise is the difference between type inference and required-key validation.

Consider:

Value = not-a-number

The importer could represent that value as a string, so it was not necessarily invalid for DynamoDB.

But this:

PK = <missing>

cannot produce a valid item for a table whose primary key requires PK.

That is why the second case produced a blocking validation error while the first did not.

When investigating rejected or unexpected CSV imports, it helps to separate these questions:
1. Can the source value be represented as a DynamoDB type?
2. Does the resulting item satisfy the target table's required key structure?

They are related to import validation, but they are not the same check.

Why read-back verification matters
Import tools can tell us whether an operation started, completed, or encountered validation errors.

But when correctness matters, it is useful to verify the resulting DynamoDB state independently.

For this exercise, the strongest recovery evidence was not simply that the corrected preview said:

Preview validation passed.

It was that the corrected item could subsequently be read from the table with the expected key and values.

A useful validation workflow is therefore:

CSV source
   ↓
Preview and mapping
   ↓
Validation
   ↓
Import
   ↓
DynamoDB read-back

If validation fails, correct the source or mapping and repeat the same path rather than assuming the failed records were written.

Conclusion
CSV imports into DynamoDB become easier to troubleshoot when validation is treated as part of the workflow rather than just a gate before the import.

Using Tables, I was able to inspect inferred values, reproduce a controlled missing-key failure, see the import blocked before proceeding, correct the affected records, retry the operation, and verify the recovered data in DynamoDB.

The test also demonstrated why apparent data-type problems and required-key problems should be investigated separately. A value such as not-a-number may still be valid as a DynamoDB string, while a missing required partition or sort key prevents the item from satisfying the table's key schema.

Most importantly, don't stop verification at “Import completed.”

For repeatable CSV-to-DynamoDB workflows, a stronger process is:
preview → validate → import → read back.

That final read-back provides evidence of what actually reached DynamoDB.

Give it a try on https://tables.serverlesscreed.com/

Exporting DynamoDB Data Safely to CSV with Tables

Arya Hegiste — Tue, 06 Oct 2026 18:14:53 +0000

Exporting DynamoDB data to CSV sounds straightforward until the dataset contains values that spreadsheets interpret differently from plain text.

Formula-like strings such as =2+3, Unicode text, commas, quotes, embedded newlines, nested DynamoDB values, binary data, booleans, and nulls can all make a seemingly simple export more interesting.

In this walkthrough, I used Tables by Serverless Creed to export a controlled DynamoDB dataset to CSV and verified both the raw file and its behavior when opened in Microsoft Excel.

The goal was to answer a simple question:

Can a DynamoDB result be exported to CSV without losing its structure or allowing formula-like strings to execute unexpectedly in a spreadsheet?

Test setup
I created a disposable DynamoDB table named:

TC-EXP-002-Blog

The table used a composite primary key:

PK  — String
SK  — String

It was created in ap-south-1 using on-demand billing.

I inserted eight controlled items covering several CSV edge cases:

Formula-like strings such as =2+3, +1+2, @formula-test, and -10+5
Unicode text: नमस्ते 日本語 🚀
Commas inside values
Double quotes
An embedded newline
Nested maps and lists
A null value
Binary data
Numbers and booleans

AWS CLI verification confirmed that the table contained exactly eight items:

Count: 8
ScannedCount: 8

Configuring the CSV export
From the table's data workspace, I opened Export and selected CSV as the output format.

The export review screen showed several useful details before any file was written:

Export mode: Streaming
Scope: All matching rows across all pages
Format: CSV
Privacy: Original values
File safety: Atomic replacement
Destination: Local file

The interface also displayed an important spreadsheet-safety message:

Formula-like strings and column names receive a leading apostrophe.

This matters because applications such as Excel can interpret values beginning with characters such as =, +, -, or @ as formulas rather than ordinary data.

Inspecting the raw CSV first
After exporting the eight rows, I deliberately inspected the CSV as a raw text file before opening it in Excel.

This is an important verification step. A spreadsheet application can transform or interpret CSV values while opening the file, so looking only at Excel does not necessarily tell us what the exporter actually wrote.

The raw file contained entries such as:

'=2+3
'+1+2
'@formula-test
'-10+5

The leading apostrophe was present in the exported data.

That means the current export successfully neutralized the formula-like strings before they reached the spreadsheet.

The raw CSV also preserved the Unicode value:

नमस्ते 日本語 🚀

Other edge cases were visible as well.

A value containing quotes was CSV-escaped appropriately, while comma-containing values were quoted. The embedded newline remained part of its quoted CSV field.

Nested DynamoDB data was serialized into string representations suitable for the flattened CSV format.

Binary data containing Hello appeared as:

`SGVsbG8=`

The null attribute was represented as an empty CSV field.

Opening the export in Excel
I then opened the same CSV file directly in Microsoft Excel.

The most important result was that the formula-like values were no longer executed.

Instead of:

=2+3 → 5
+1+2 → 3
-10+5 → -5

the exported values remained text.

This confirms that the spreadsheet-safety transformation visible in the raw CSV prevented these values from being evaluated as formulas in this test.

Numbers and boolean values were also retained, and the CSV structure remained readable.

One important Unicode observation
There was, however, a difference between the raw file and Excel.

The raw CSV contained the expected Unicode text:

नमस्ते 日本語 🚀

When I opened the CSV directly in my Excel environment, that text displayed as garbled characters.

This distinction is important.

The raw-file inspection showed that the Unicode data existed correctly in the exported file. Therefore, the evidence from this test does not show that Tables destroyed the Unicode value during export.

Instead, the issue appeared during the way this Excel environment interpreted the CSV when opening it directly.

This is exactly why checking both the raw output and the spreadsheet representation is useful.

Testing export failure and recovery
I also wanted to verify what happened when the destination itself was invalid.

During another export, I deliberately entered the following Windows filename:

TC-EXP-002:invalid.csv

Because : is not permitted in a normal Windows filename, the operating system rejected it with:

The file name is not valid.

The invalid destination therefore did not produce a final CSV presented as a successful export.

I then corrected the destination to:

TC-EXP-002-Blog-Recovery.csv

and retried the export.

The corrected export downloaded successfully.

This provided a simple failure-and-recovery check without modifying the DynamoDB source data.

A useful lesson: verify the file at two levels
The most useful lesson from this test was not simply that the export completed successfully.

It was that CSV verification should happen at two different levels.

First, inspect the raw file to determine what the exporter actually produced.

Then open the file in the intended consumer, such as Excel, to determine how that application interprets it.

Those are not always the same thing.

In this test, the raw CSV proved that formula-like strings were neutralized and Unicode text was present correctly. Excel confirmed the formula-safety behavior, but its direct CSV-opening path displayed the Unicode value incorrectly.

Without inspecting the raw file first, it would have been easy to incorrectly attribute that display behavior to the exporter.

Conclusion
Tables provided a straightforward streaming workflow for exporting DynamoDB results to CSV, while also exposing important behaviors before the export was started.

For this controlled eight-item dataset, the export:

preserved CSV structure for commas, quotes, and newlines;
serialized complex DynamoDB values;
preserved numbers, booleans, nulls, and binary data in appropriate CSV representations;
neutralized formula-like strings before spreadsheet use;
preserved the tested Unicode value in the raw file; and
recovered cleanly after an invalid destination filename was rejected.

The Excel test also highlighted an important practical point: a correct CSV file and a correct spreadsheet rendering are two separate things worth verifying.

For DynamoDB exports that may eventually be opened in spreadsheet software, checking both makes the export much easier to trust.