Skippr Docs

Appearance

DynamoDB CDC to Redshift Final-State Guide ​

June 2026

DynamoDB to Redshift CDC is mostly about translating item mutations into a disciplined staging-and-MERGE workflow.

Short Answer ​

DynamoDB CDC to Redshift works by turning item-level stream records into a staging batch that Redshift can MERGE into the target table. DynamoDB emits INSERT, MODIFY, and REMOVE events; Skippr loads those changes into a Redshift staging table and then applies MERGE with order-token guards so older mutations do not win.

The destination-specific wrinkle is the Redshift staging path. Redshift loads through an S3 COPY workflow, so the pipeline needs both a clean warehouse contract and a clean staging setup. Once the batch is in staging, MERGE is what turns the feed into a final-state table rather than an append-only log.

Why Teams Struggle with This ​

A lot of teams focus on the AWS-to-AWS network path and miss the harder part: making sure the Redshift table means the same thing as the DynamoDB item after retries and deletes.

  • Composite DynamoDB item keys need to be preserved in the Redshift merge key.
  • S3 staging configuration can be correct while the merge contract is still wrong.
  • REMOVE events need tombstone handling so older inserts cannot reappear.
  • Treating the staging table as disposable often hides ordering and identity mistakes.

How Skippr Handles It ​

Skippr uses DynamoDB Streams directly and stores per-shard sequence numbers for restart safety, so the change feed resumes from a known position after interruptions.

For Redshift, Skippr uses the documented staging-table plus MERGE pattern, adds _skippr_order_token automatically, and creates tombstone tables for delete protection. That keeps source sequencing and warehouse reconciliation in one pipeline instead of splitting them across ad hoc jobs.

  • DynamoDB item mutations are captured from Streams with durable shard positions.
  • Redshift COPY loads feed a staging table before MERGE runs.
  • MERGE uses order-token guards to reject stale writes.
  • Deletes are recorded in tombstones before target rows are removed.

What the First Useful Version Looks Like ​

This integration is a good match when Redshift is already the reporting surface and the team wants DynamoDB changes to arrive as usable current-state rows.

The key is not just staging into Redshift. It is using staging as the bridge to a table whose row identity and delete behavior are explicit.