How DynamoDB CDC Delete Events Behave in a Warehouse

May 2026

A DynamoDB delete is not finished when a REMOVE record appears. It is finished when the warehouse applies that delete with the right key and replay protection.

Short Answer

In DynamoDB CDC, a delete starts as a REMOVE stream record. In a supported final-state destination, Skippr applies that delete by business key, records a tombstone with the order token, and removes the row from the target table. That is what makes the warehouse state trustworthy after replay, not just the fact that the source emitted a delete.

For example, if item pk = "order#42" is removed from DynamoDB, the destination contract is not merely "a delete happened." The useful outcome is that the warehouse row for that logical item disappears, and an older replayed insert for the same business key cannot bring it back if its order token is older than the tombstone.

Why Teams Struggle with This

Delete handling is where CDC often stops being abstract. A warehouse table needs a durable rule for what happens when the source says a row is gone and later retries deliver older competing mutations.

• A delete needs the right business key, because reconciliation is defined per logical row.
• A hard delete alone is not enough for replay safety; the tombstone record is what protects against resurrection.
• Older inserts or updates must lose to the newer delete when order tokens are compared.
• If the destination cannot maintain final-state reconciliation, the CDC outcome is CDC-encoded rather than exactly-once final state.

How Skippr Handles It

Skippr makes DynamoDB delete behavior easier to reason about because the source and destination pieces line up in one contract. The source supplies delete mutations from Streams, and the destination docs explain how those deletes are turned into final-state behavior with tombstones and guarded apply logic.

That matters because delete bugs are usually warehouse bugs in disguise. The stream record is only the start. The warehouse rule is what decides whether analytics users see the correct state after retries.

• DynamoDB REMOVE events become delete mutations in the CDC stream.
• Final-state destinations create companion tombstone tables automatically.
• The tombstone keeps an older replayed insert from restoring a deleted row.
• The warehouse contract still depends on explicit business keys.

What the First Useful Version Looks Like

The practical test for a DynamoDB delete is simple: after a retry, does the warehouse still show the row as deleted? If the answer depends on luck, the CDC design is not done.

Skippr gives that delete a documented warehouse rule instead of leaving it to downstream cleanup.