How to Define DynamoDB Ingestion Scope Clearly

July 2026

A clean DynamoDB boundary starts with one table name and one region. If you later turn on CDC, you are still following the life of that same table, not creating a new arbitrary slice.

Short Answer

Define DynamoDB ingestion scope as one table_name in one region. The source docs keep the connector that direct on purpose. Batch mode reads that table with DescribeTable and Scan, and CDC mode follows changes from DynamoDB Streams for that same table when you set cdc_enabled: true and pair it with a supported destination.

That is why a config such as table_name: orders and region: us-east-1 is already a concrete boundary. It means Skippr is responsible for the full orders table in that region. A custom endpoint_url can matter for LocalStack or another test setup, but it does not change the production boundary. It only changes which API endpoint the connector talks to.

Why Teams Struggle with This

DynamoDB projects get vague when teams speak as if they are ingesting "some order items" even though the connector reads an entire table and, if CDC is enabled, the mutation stream behind that same table. The table boundary should be explicit much earlier than the CDC discussion.

• Using one broad table for many unrelated entity shapes makes the source boundary harder to explain downstream.
• A correct AWS principal still does not make the table scope clear if no one has named the exact production table and region.
• Treating Streams CDC as a new source hides the important fact that it is still mutation capture for one table contract.
• Leaving a custom endpoint_url in place from local testing can send the connector to the wrong system while everyone thinks the table name is the problem.

How Skippr Handles It

Skippr helps here by keeping the DynamoDB connector small: table_name, region, and optional endpoint_url. That leaves little room to pretend the source is something fuzzier than one named table.

The connector also makes the staged path obvious. Teams can validate one table with scans first, then add Streams-based CDC when they want the warehouse to stay aligned to current item state.

• Treats a single DynamoDB table as the primary source boundary.
• Uses the AWS default credential chain rather than a separate secret model.
• Extends from scan reads to Streams CDC without changing the underlying table contract.
• Produces a namespace keyed to the table name, which keeps the source identity visible.

What the First Useful Version Looks Like

The first useful version is one table such as orders, one region, and one AWS principal that can describe and scan it. That is enough to validate shape, keys, and access before you add mutation capture.

If you only want a narrow business slice, do not leave the table boundary vague. Either expose a purpose-built upstream table or keep the full table as the source and model the narrower slice downstream.