How DynamoDB CDC Resume Behavior Works

May 2026

DynamoDB CDC resume behavior is per shard. Skippr stores the last processed sequence number for each shard and uses it when the pipeline starts again.

Short Answer

DynamoDB CDC resume behavior is documented per shard. After each committed change batch, Skippr stores the sequence number of the last processed record for each shard. On restart, it requests a shard iterator from AT_SEQUENCE_NUMBER using that stored value. If a shard is new, Skippr starts it from TRIM_HORIZON.

That design matters because DynamoDB Streams are not a single linear cursor for the whole table. Resume has to account for shard boundaries. The useful way to think about restart safety is not "did the job remember roughly where it was." It is "did each shard resume from a committed sequence number."

Why Teams Struggle with This

Resume logic gets confusing when teams imagine DynamoDB Streams as one simple offset. The docs describe a more precise model: one stored position per shard, plus explicit handling for newly discovered shards.

• Restart safety is tied to committed batches, not to an in-memory best guess.
• Each shard has its own stored sequence number.
• New shards do not inherit an old shard position; they start from TRIM_HORIZON.
• The general CDC guarantee still stops if source retention expires before the runner resumes.

How Skippr Handles It

Skippr keeps the resume model concrete instead of hand-wavy. The source docs state exactly what gets stored and exactly how restart begins again for DynamoDB Streams.

That helps downstream too. If the warehouse applies a committed change batch and the source cursor is stored at that same boundary, the final-state reconciliation has a much clearer recovery story.

• Sequence numbers are stored per shard after each committed change batch.
• Restarts use AT_SEQUENCE_NUMBER for known shards.
• New shards begin at TRIM_HORIZON.
• Resume is tied to committed source progress rather than a loose checkpoint.

What the First Useful Version Looks Like

DynamoDB restart behavior is easiest to trust when you remember that the cursor lives at the shard level. That is the detail that makes the resume story specific instead of magical.

Once that is clear, recovery questions become much easier to answer.