How PostgreSQL CDC Resume Behavior Works
May 2026
PostgreSQL CDC resume behavior is built on committed LSNs and a reused replication slot. The slot is not recreated on every restart.
Short Answer
PostgreSQL CDC resume behavior in Skippr uses the committed LSN. After each committed change batch, Skippr stores the LSN. On restart, replication resumes from that stored position. The replication slot is reused across restarts rather than recreated.
That second detail is important. The docs say PostgreSQL retains WAL segments only until Skippr has confirmed them, because the same slot is preserved across restarts. The result is a concrete recovery model: one durable logical-replication cursor and one durable slot tracking what has been acknowledged.
Why Teams Struggle with This
Restart behavior becomes much easier to explain when you separate two things: where the stream should resume, and what PostgreSQL should retain until that point is confirmed. The docs address both pieces explicitly.
- The durable source cursor is the committed PostgreSQL LSN.
- That LSN is stored after each committed change batch.
- The replication slot is reused across restarts instead of being recreated each time.
- PostgreSQL retains WAL segments only until Skippr has confirmed them through that slot.
How Skippr Handles It
Skippr keeps PostgreSQL restart behavior close to the source mechanism itself. The WAL position and the replication slot are native PostgreSQL concepts, so operators do not have to learn an extra abstraction to understand recovery.
That also strengthens the warehouse-side story. If final-state tables are updated from committed change batches and the source cursor is stored at those same committed boundaries, retries and restarts are much easier to reason about.
- Committed LSNs are stored after each committed change batch.
- Restarts resume logical replication from the stored LSN.
- The same replication slot is reused across restarts.
- WAL retention follows confirmation on that slot rather than a recreated fresh stream.
What the First Useful Version Looks Like
PostgreSQL gives you a very concrete restart story for CDC: resume from the committed LSN and keep using the same slot. That is far better than a vague "best effort" checkpoint.
Once you understand those two pieces, most restart questions answer themselves.
