Skippr Docs

Appearance

When to Choose PostgreSQL for CDC Final State ​

May 2026

Choose PostgreSQL for CDC final state when you want PostgreSQL to own the reconciled table and the staging-plus-upsert pattern fits how you want changes applied.

Short Answer ​

Choose PostgreSQL when you want the final-state table to live in PostgreSQL itself and you want Skippr to apply CDC with the documented staging-table plus INSERT ... ON CONFLICT pattern. In this model, Skippr adds a _skippr_order_token column, compares newer and older changes during apply, and creates companion tombstone tables for deletes.

That is a good fit when the warehouse contract you want is straightforward: a PostgreSQL schema, explicit business keys, and final-state reconciliation that happens close to ingestion. The important point is not just that PostgreSQL can store rows. It is that the documented apply pattern matches how you want upserts and deletes to behave after retries.

Why Teams Struggle with This ​

Teams often choose a destination as if every warehouse handles CDC the same way. The docs make clear that they do not. PostgreSQL uses a specific reconciliation pattern, and that pattern should be part of the choice.

  • Final-state correctness depends on a business key, because reconciliation is defined per logical row.
  • Older mutations must lose to newer ones, which is why the order-token column matters.
  • Deletes need a durable record so an older replayed insert cannot resurrect a row that should stay gone.
  • The PostgreSQL user still needs the documented database and schema permissions to create and write the managed tables.

How Skippr Handles It ​

Skippr is useful here because the PostgreSQL destination behavior is already documented in the CDC contract. The table gets an order-token column, deletes go through tombstone handling, and the apply path is not left to an ad hoc downstream model.

That makes PostgreSQL a sensible choice when you want the warehouse semantics to stay easy to inspect. The same project can define the source CDC settings, the business key, and the destination apply behavior without splitting those decisions across separate tools.

  • Exactly-once final-state reconciliation is documented for the PostgreSQL destination.
  • The apply path uses staging plus guarded upsert logic instead of blind overwrite behavior.
  • Tombstone tables are created automatically for CDC-managed tables.
  • Authentication and schema permissions are documented with standard PostgreSQL environment variables.

What the First Useful Version Looks Like ​

PostgreSQL is the right choice when you specifically want PostgreSQL tables as the final-state product and the documented staging-and-upsert semantics match the way your team wants CDC to reconcile.

If that is the table contract you want to support, PostgreSQL is not just acceptable. It is the destination whose documented behavior already matches the job.