What DynamoDB CDC Capture Shape Looks Like

May 2026

DynamoDB CDC capture shape is item-level stream activity, not a generic table diff. The useful question is which stream records exist and what item images they carry.

Short Answer

DynamoDB CDC capture shape is the shape of DynamoDB Streams records for one table: INSERT, MODIFY, and REMOVE. Skippr requires Streams to be enabled with StreamViewType = NEW_AND_OLD_IMAGES, then reads shard iterators and turns those item-level records into CDC mutations with mutation kind and order-token metadata.

A concrete example helps. If item { pk: "order#42", status: "placed" } becomes { pk: "order#42", status: "shipped" }, the meaningful capture shape is not "something changed in the table." It is a single item mutation for one key. If the item disappears, the stream emits REMOVE. If a new item appears, the stream emits INSERT. That item-level view is the whole point.

Why Teams Struggle with This

People sometimes picture DynamoDB CDC as a warehouse-style diff between snapshots. The docs describe something more specific: item changes read from DynamoDB Streams with the stream view configured to expose the item state needed for CDC.

• CDC depends on DynamoDB Streams being enabled for the table before Skippr can read change records.
• The docs require NEW_AND_OLD_IMAGES, because CDC needs enough item state to express inserts, updates, and deletes cleanly.
• The capture unit is the item, not a multi-row transaction batch shaped like a SQL binlog event.
• Skippr emits CDC mutations with mutation kind and ordering metadata, but the public docs do not spell out a broader custom event schema beyond that.

How Skippr Handles It

Skippr keeps the DynamoDB source design practical. The docs tie the prerequisite, the event types, and the resume behavior together instead of treating them as unrelated setup fragments.

That helps because DynamoDB CDC is easy to misunderstand if you come from relational logs. Skippr stays close to the supported source behavior: stream records, shard iterators, and item-level mutations that can be reconciled downstream.

• DynamoDB CDC is based on DynamoDB Streams, not polling full table snapshots.
• The required stream view is NEW_AND_OLD_IMAGES.
• Captured event kinds are INSERT, MODIFY, and REMOVE.
• The resulting CDC path carries mutation kind and order-token metadata into the destination contract.

What the First Useful Version Looks Like

If you understand DynamoDB CDC as item-level stream records, most of the design gets easier. You stop asking for a generic event diary and start asking whether each item mutation can be replayed and reconciled cleanly.

That is the right mental model for the source.