Skippr Docs

Appearance

DynamoDB CDC to Postgres Final-State Guide ​

June 2026

DynamoDB to Postgres CDC depends on good key design and a deliberate staging-and-upsert pattern.

Short Answer ​

DynamoDB CDC reaches PostgreSQL final state through a staging-table pattern. Skippr reads INSERT, MODIFY, and REMOVE records from DynamoDB Streams, loads the batch into staging, and then applies INSERT ... ON CONFLICT with an order-token guard so newer item versions win.

The destination-specific difference is that PostgreSQL relies on the conflict key you define. If a DynamoDB table uses both a partition key and sort key, PostgreSQL must use that full logical identity in its conflict target. Otherwise the integration will look like it works while quietly merging different items into the same row.

Why Teams Struggle with This ​

This setup usually fails in design rather than infrastructure. PostgreSQL is familiar, so teams assume the upsert path is obvious when it is actually where correctness lives.

  • DynamoDB composite keys are easy to flatten incorrectly into a single incomplete identifier.
  • Staging tables get treated as temporary plumbing instead of part of the correctness model.
  • REMOVE events need tombstone tracking or older inserts can come back after replay.
  • A plain upsert without an order-token comparison can let stale mutations overwrite newer state.

How Skippr Handles It ​

Skippr keeps the source side simple and documented: DynamoDB Streams provides the change feed, and shard sequence numbers are stored for restart safety. That gives the pipeline a durable stream position without custom offset tables.

On PostgreSQL, Skippr creates _skippr_order_token and tombstone tables, then reconciles from staging with INSERT ... ON CONFLICT ... DO UPDATE WHERE the incoming token is newer. That makes the destination behavior reviewable instead of implicit.

  • DynamoDB stream records are captured with item-level mutation fidelity.
  • PostgreSQL staging tables support bulk loading before reconciliation.
  • ON CONFLICT updates are gated by _skippr_order_token comparisons.
  • Tombstone tables preserve delete intent and block stale reinserts.

What the First Useful Version Looks Like ​

Choose this setup when PostgreSQL is the warehouse endpoint and you want a compact, explicit reconciliation model.

The main design task is carrying DynamoDB row identity into the conflict key exactly as the source table uses it.