Skippr Docs

Appearance

What Access Skippr Needs to Read from PostgreSQL ​

June 2026

PostgreSQL access changes meaningfully when you move from table reads to WAL logical replication, and Skippr needs those two cases kept separate.

Short Answer ​

Skippr needs a PostgreSQL user that can read the selected tables or views and a runner that can reach the Postgres host and port. If you enable CDC, PostgreSQL also has to support WAL logical replication with wal_level = logical, max_replication_slots set to at least 1, and a replication user that has the REPLICATION attribute or superuser access.

A common setup starts with a normal read user on database appdb for batch extraction. When the team wants ongoing change capture, that usually becomes a dedicated replication user such as replicator, a publication like skippr_pub, and a replication slot such as skippr_slot, because Skippr streams row changes through pgoutput rather than polling tables forever.

Why Teams Struggle with This ​

Postgres access often fails at the seam between ordinary SQL permissions and replication permissions. A login can query tables all day and still be useless for CDC because the server configuration or user attributes do not allow logical replication.

  • Batch extraction needs read access to the tables or views you configure.
  • CDC requires wal_level = logical and at least one replication slot to be available.
  • The replication user must have the REPLICATION attribute or be a superuser.
  • Host, port, SSL behavior, and database choice still matter because logical replication cannot start if the normal connection path is already wrong.

How Skippr Handles It ​

Skippr keeps the PostgreSQL source contract understandable because the access surface stays close to PostgreSQL itself: host, port, database, user, password, optional tables, and optional query. Then the CDC guide adds the exact replication prerequisites rather than pretending table access alone will cover both modes.

That makes operations easier to reason about. Skippr stores the committed LSN after each change batch and resumes from that position, while the replication slot is reused across restarts, so the database configuration and replication grants directly shape reliability.

  • Supports normal table or view reads through a standard Postgres connection.
  • Uses WAL logical replication with pgoutput when CDC is enabled.
  • Relies on a publication and replication slot for durable change capture.
  • Stores the committed LSN so restarts resume from the last confirmed position.

What the First Useful Version Looks Like ​

The first useful version is one Postgres database, one clearly scoped read user, and one or two tables that prove the base connection and schema boundary are correct.

If the real destination needs current-state CDC, verify the replication settings and user attributes before you design downstream tables, because the source contract gets stronger the moment CDC is enabled.