Skippr Docs

Appearance

Postgres CDC to Redshift Final State Guide ​

June 2026

Postgres to Redshift is an integration where WAL ordering has to survive an S3 staging step before the final MERGE happens.

Short Answer ​

Postgres CDC to Redshift works by streaming row-level changes from PostgreSQL logical replication, staging those changes through Redshift COPY, and then reconciling the target table with MERGE. Skippr turns the PostgreSQL log position into the destination order token, adds _skippr_order_token VARCHAR(MAX) columns automatically, and records deletes in tombstone tables so stale replays do not win later.

A concrete example is public.subscriptions id 14 being deleted after cancellation. PostgreSQL emits the delete through the replication slot, Skippr preserves its committed LSN ordering, and Redshift writes the tombstone and removes the row during reconciliation. If an older insert for id 14 is replayed after a restart, the tombstone blocks it.

Why Teams Struggle with This ​

This pipeline has more moving parts than a direct database destination because the ordered WAL stream has to cross a staging boundary. PostgreSQL still needs logical replication enabled and healthy slot reuse, while Redshift also needs a reachable staging S3 bucket and an IAM role it can use to read those files.

  • PostgreSQL CDC requires wal_level = logical, a replication slot, and a replication-capable user.
  • PostgreSQL retains WAL only until Skippr has confirmed it through the reused replication slot.
  • Redshift reconciliation depends on COPY to staging followed by MERGE, not on direct row-by-row updates.
  • Deletes need tombstones so replayed older inserts cannot restore removed rows.

How Skippr Handles It ​

Skippr keeps the pipeline ordered even though it is staged. It stores the committed LSN after each committed batch, resumes the PostgreSQL stream from that point, stages the corresponding rows in Redshift, and then MERGEs them with token comparison so the newest mutation wins for each key.

That makes the pipeline easier to trust after an interruption. You can explain that the same LSN that defined resume order also defined the Redshift merge decision, even though the batch crossed S3 on the way.

  • PostgreSQL logical replication with durable LSN resumes.
  • Redshift COPY staging before MERGE reconciliation.
  • Order-token guards so older WAL mutations lose to newer ones.
  • Automatic tombstone tables for delete protection.

What the First Useful Version Looks Like ​

Choose this integration when Redshift is the warehouse of record for current-state analytics and PostgreSQL is the application database.

The pipeline stays healthy when the team treats the staging step as part of the correctness path, not as invisible transport plumbing.