Skippr Docs

Appearance

Postgres CDC to Synapse Final State Guide ​

June 2026

Postgres to Synapse is an integration where committed WAL order has to survive the trip into MERGE-based warehouse reconciliation.

Short Answer ​

Postgres CDC to Synapse works by streaming inserts, updates, and deletes from PostgreSQL logical replication and applying them with Synapse MERGE statements. PostgreSQL supplies committed LSN ordering and full row after images for updates. Synapse supplies the _skippr_order_token NVARCHAR(4000) column and the companion tombstone table so the destination only accepts a mutation when its token is newer than the token already stored for that key.

A concrete example is public.accounts id 700 moving from state "trial" to "active". PostgreSQL emits the update through the replication slot, Skippr carries that ordered change into Synapse, and MERGE updates the target row only when the incoming token wins. If the account row is deleted later, Synapse records the tombstone and removes the row so an older replayed insert cannot restore it.

Why Teams Struggle with This ​

This integration combines PostgreSQL replication requirements with Synapse connection requirements. The source needs wal_level = logical, a reusable replication slot, and a replication-capable user. The destination needs a valid ADO.NET connection string and write access to the target schema before MERGE can preserve final state.

  • PostgreSQL CDC requires pgoutput-based logical replication and committed LSN tracking.
  • Updates arrive as full row after images, which is what gives Synapse a full replacement candidate for each key.
  • MERGE correctness depends on comparing _skippr_order_token values rather than trusting arrival order.
  • Deletes still need tombstones so replayed older inserts cannot bring removed rows back.

How Skippr Handles It ​

Skippr makes the integration easier to operate because the source order and destination order use the same token story. It stores the committed LSN after each committed batch, resumes PostgreSQL from that point, and applies those changes in Synapse with MERGE and automatic tombstone creation. There is no separate replay policy to invent later.

That clarity shows up during debugging. If a Synapse row looks wrong, you can inspect which LSN won, whether the incoming mutation was older, and whether a tombstone had already marked the key as deleted.

  • PostgreSQL logical replication with durable LSN-based resumes.
  • Synapse MERGE reconciliation with _skippr_order_token guards.
  • Automatic tombstone tables for delete protection.
  • A deterministic pipeline from committed PostgreSQL changes to current-state Synapse rows.

What the First Useful Version Looks Like ​

Choose this integration when Synapse is the current-state destination that downstream consumers query and PostgreSQL is the transactional source.

The integration becomes much simpler once everyone agrees that the committed LSN is the ordering authority all the way through the Synapse MERGE.