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

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