DynamoDB CDC to Snowflake Final-State Guide
June 2026
DynamoDB to Snowflake CDC succeeds when Snowflake is treated as the place where item mutations become a reliable final-state table.
Short Answer
DynamoDB CDC to Snowflake means converting DynamoDB Streams item events into Snowflake row state. The source emits INSERT, MODIFY, and REMOVE records, and Skippr applies them with Snowflake MERGE DML so the target table is keyed to the logical item rather than to the event stream.
What changes for Snowflake is that delete handling and row updates can be wrapped in transactional warehouse logic. Skippr records a tombstone and deletes the target row in the documented Snowflake MERGE flow, so a stale replayed insert cannot bring back an item that was already removed later.
Why Teams Struggle with This
Snowflake makes it easy to focus on the warehouse interface and forget the item semantics upstream. That is backwards for this integration.
- DynamoDB items can have composite identity, so the Snowflake merge key must match the source table design.
- Stream enablement must use NEW_AND_OLD_IMAGES if you want the full item state the pipeline assumes.
- Delete correctness depends on tombstones, not just on removing rows from the target table.
- Warehouse replays become dangerous without an explicit newer-wins comparison.
How Skippr Handles It
Skippr reads shard iterators from DynamoDB Streams, stores the last committed sequence number per shard, and resumes from that position after restart. That makes the source feed durable without inventing a custom stream processor.
Snowflake then gets a CDC-managed table with _skippr_order_token plus a companion tombstone table, and MERGE DML enforces the final-state rules. Upload staging may vary by Snowflake setup, but final-state correctness is defined by the MERGE contract.
- DynamoDB INSERT, MODIFY, and REMOVE events are captured natively.
- Per-shard sequence numbers preserve restart position.
- Snowflake MERGE applies only newer item versions.
- Tombstone rows block ghost resurrections after deletes.
What the First Useful Version Looks Like
Use this integration when DynamoDB is operational storage and Snowflake is where analysts need a stable current-state table.
The warehouse wins here because it can express delete protection and newer-wins updates directly, but only if the item key from DynamoDB stays intact.
