Skippr Docs

Appearance

Postgres CDC to MotherDuck Final State Guide ​

June 2026

Postgres to MotherDuck works when WAL changes arrive with enough identity and ordering to keep one current row per key.

Short Answer ​

Postgres CDC to MotherDuck works by streaming inserts, updates, and deletes from PostgreSQL logical replication and reconciling them in MotherDuck with DuckDB-style MERGE behavior. Skippr uses INSERT OR REPLACE guarded by order-token comparison for upserts, and it uses tombstone inserts plus DELETE with a tombstone join for deletes. The LSN-derived _skippr_order_token is what tells MotherDuck which version is newer.

For example, if users.id 53 changes email from old@example.com to new@example.com, PostgreSQL emits the full after image and Skippr carries that row plus its ordering token into MotherDuck. The row is only replaced if that token is newer than the one already attached to id 53. If users.id 53 is deleted later, the tombstone blocks any older replayed insert from restoring it.

Why Teams Struggle with This ​

Even though the destination is simpler to operate than a larger warehouse, the source-side replication details still matter. PostgreSQL has to stream logical changes from WAL through a reusable slot, and MotherDuck still depends on token-guarded upserts to preserve final state during retries.

  • PostgreSQL CDC requires wal_level = logical, a replication slot, and a replication-capable user.
  • Updates arrive as full row after images, which lets MotherDuck replace the whole current row deterministically.
  • MotherDuck upserts still need a stable key plus token comparison to reject stale replays.
  • Deletes rely on tombstones so a removed key stays removed even if an older insert is replayed later.

How Skippr Handles It ​

Skippr keeps the integration compact without hiding the CDC rules. It stores committed LSN values after each batch, resumes logical replication from that point, creates the MotherDuck order-token and tombstone tables automatically, and applies the documented replacement logic for newer rows.

That gives the integration a simple operating model with a real correctness contract. You can explain the winning update or delete using the same source ordering token that made the restart behavior safe.

  • PostgreSQL logical replication with durable committed-LSN resumes.
  • MotherDuck INSERT OR REPLACE behavior guarded by order tokens.
  • Automatic tombstone tables for delete handling.
  • A clear current-state contract for rows that started in PostgreSQL.

What the First Useful Version Looks Like ​

This integration is a strong choice when MotherDuck is where the team wants queryable current-state tables but PostgreSQL is still the operational source.

The fastest way to keep it boring is to make sure the Postgres key, the MotherDuck key, and the tombstone key are all the same identity.