Skippr Docs

Appearance

What Network Access Skippr Needs for PostgreSQL ​

June 2026

PostgreSQL source access means the runner can reach the configured host and port and the user can read the tables you selected.

Short Answer ​

Skippr needs outbound access to the PostgreSQL host and port, along with a user that can read the selected tables or views. The source docs show the connector as host, port, user, password, and database, or one overriding connection_string, so the practical boundary is the exact socket the runner must open, typically on port 5432, plus the database objects that user is allowed to read.

That boundary becomes obvious in mixed environments. A database may be reachable from a bastion host but not from CI, or a shared Postgres server may allow login while the chosen user cannot read the public.orders table you expected to ingest. If CDC is part of the plan, the docs also point you to PostgreSQL logical replication prerequisites, which extend the access conversation beyond ordinary table reads.

Why Teams Struggle with This ​

PostgreSQL is familiar enough that teams sometimes wave away the network question too early. In practice, source readiness still depends on the boring details: the right host, the right port, the right database, and read access that exists where Skippr is actually running.

  • The runner must reach the configured Postgres host and port from its own network segment.
  • The database user needs read access to the selected tables or views.
  • A successful login is not the same as a usable extraction boundary if the wrong database or table list is selected.
  • CDC needs the normal network path plus PostgreSQL logical replication prerequisites from the CDC guide.

How Skippr Handles It ​

Skippr keeps PostgreSQL access explicit instead of hiding it behind a generic database connector. You can supply the host, port, database, and credentials directly, or override them with a connection string when that better matches the way your team manages DSNs.

That makes the first connectivity check operationally meaningful. If the runner can open the Postgres connection, read the intended tables, and land a small extract, then the source boundary is real. If it cannot, you know the problem lives in host reachability, credentials, or object permissions rather than in the rest of the pipeline.

  • Supports direct host, port, database, and credential fields or a full connection string.
  • Reads explicit tables or a custom query when that is the intended source boundary.
  • Uses environment-variable password handling for safer deployment.
  • Extends naturally into CDC once logical replication prerequisites are satisfied.

What the First Useful Version Looks Like ​

The first useful version is one Postgres host, one database, and a short table list that proves the source can be read from the same runtime environment you will use later.

If you need CDC, keep the first batch validation separate. A clean table-read path makes the replication follow-up much easier to reason about.