Skippr Docs

Appearance

How DynamoDB Defines the Raw Data Contract ​

July 2026

For DynamoDB, raw data means the items stored in one table, scoped by table name and region, not a relational join or an inferred analytics model.

Short Answer ​

The raw data contract for DynamoDB is the item shape from one named table in one region. Skippr starts by reading that table directly, so the raw layer is the current item representation the table exposes, landed under the pipeline name (same as S3), not a set of joins or an analytics-ready star schema.

That matters because the table design is the contract. If accounts stores one item per account with nested plan details and feature flags, the raw layer is that item structure. If the team later enables cdc_enabled: true, Skippr can also consume DynamoDB Streams, but the underlying record identity is still the table item, not a new warehouse-defined shape.

Why Teams Struggle with This ​

DynamoDB causes confusion when teams expect it to behave like a relational source with hidden normalization waiting underneath. The source connector reflects the table as designed, so denormalized items, nested attributes, and key-based access patterns show up directly in the raw layer.

  • The table_name and region pair define the boundary of the raw contract.
  • Batch reads tell you what the table stores now, while Streams-based CDC later tells you how those items change over time.
  • A custom endpoint such as LocalStack can change where you test, but it does not change the item shape you should document for production.
  • If analysts expect joined dimensions on day one, the problem is usually the chosen source boundary, not the connector.

How Skippr Handles It ​

Skippr keeps DynamoDB intentionally narrow: table_name, region, and optional endpoint_url. That makes it easier to explain that the raw layer is just one table of items, not a broad AWS integration project.

The AWS default credential chain also keeps the focus on the table itself. You can validate the item contract with scan permissions first, then extend the same source into Streams-based CDC only when current-state warehouse tables are worth the extra operational step.

  • Reads directly from a DynamoDB table by name and region.
  • Lands the lake table under the pipeline name so warehouse names stay stable even when CloudFormation hashes the AWS table name.
  • Relies on the AWS default credential chain instead of inventing a new auth surface.
  • Can extend from scan-based reads into DynamoDB Streams CDC with cdc_enabled: true.

What the First Useful Version Looks Like ​

The first useful version is one table such as accounts, one region, and one downstream raw table review that checks item identity and nested fields. That is enough to decide whether the DynamoDB table is a good contract as-is.

If the table later needs CDC, keep the same table-level contract in view. Streams add freshness and mutation handling, but they do not change which item shape the source system is actually publishing.