DEV Community: Arya Hegiste

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.

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