Skip to content

How to Configure PostgreSQL as a Source Connector

May 2026

PostgreSQL source setup is straightforward when the team is clear on whether it wants field-based config or one DSN-style connection string.

Short Answer

Configure PostgreSQL as a source by setting source.kind to postgres_source, then supplying host, port, user, password, and database, or a full connection_string if you prefer a single DSN-style value. You can add tables to narrow the source or query if you want a shaped extract that overrides table selection entirely.

A clean first setup often uses the field-based form because it is easier to read at a glance: localhost, port 5432, a named database, and a password from POSTGRES_SOURCE_PASSWORD. From there, start with one or two public.* tables so you can verify connectivity, permissions, and schema inference before you widen the connector.

Why Teams Struggle with This

PostgreSQL source issues usually show up where connection details meet security settings. A host and port can be correct while SSL behavior or the chosen database is wrong, and a user can authenticate successfully while still lacking read access to the tables or views the pipeline needs.

  • You should choose either explicit host and credential fields or a full connection_string, then keep that style consistent.
  • Passwords or DSNs belong in environment variables such as POSTGRES_SOURCE_PASSWORD or POSTGRES_SOURCE_CONNECTION_STRING.
  • The database user needs read access to the selected tables or views.
  • The runner must reach the PostgreSQL host and port, and some environments also need the right SSL parameters.

How Skippr Handles It

Skippr exposes PostgreSQL in the same terms most teams already use operationally: host, port, database, and user, with the option to switch to a single connection string when that is easier to manage. That keeps the source readable and avoids hiding connection behavior inside a generic database abstraction.

The first valid configuration should let you answer very practical questions. Which database did Skippr connect to, which tables did it inspect, and whether the source account has the access required to support a larger extract or later logical-replication work.

  • Flexible PostgreSQL source config with either individual fields or a full connection string.
  • Optional tables and query controls for shaping the first extract.
  • Environment-based secret handling for passwords and DSNs.
  • A smooth base for later WAL logical-replication CDC setups.

What the First Useful Version Looks Like

If the environment has stricter SSL requirements, verify those parameters before assuming a wrong password is the issue.

Keep the first table list small and explicit so you can compare what Skippr reads with what Postgres shows directly in information_schema or your existing admin tools.