Skippr Docs

Appearance

How to Manage PostgreSQL Source Credentials in Skippr ​

July 2026

Keep PostgreSQL source credentials safe by separating endpoint fields from the secret, interpolating POSTGRES_SOURCE_PASSWORD or a connection-string env var, and granting only the read access the source needs.

Short Answer ​

Manage PostgreSQL source credentials in Skippr by keeping the connection target visible and only the secret hidden. The docs support either individual fields such as host, port, user, password, and database or one connection_string, and the safe pattern is to interpolate password or the full DSN from environment variables instead of writing either secret directly into skippr.yaml.

That gives you a cleaner operational split. Hostname, port, database, and table or query selection are not secrets and should remain reviewable. The password is the secret, so it belongs in POSTGRES_SOURCE_PASSWORD or a dedicated source connection-string variable that the runtime resolves at execution time.

Why Teams Struggle with This ​

PostgreSQL setups become confusing when teams either hide too much or expose too much. If everything becomes one opaque connection string, reviewers cannot see what the source is pointed at. If the password stays in YAML, the reviewable config becomes a secret leak.

  • Keeping a literal password in skippr.yaml is the most common avoidable mistake.
  • Using a full connection string can be useful, but it should still come from an environment variable if it includes credentials.
  • Switching from tables to query changes the extraction contract and should stay explicit in config.
  • If you plan to use logical replication for CDC later, the source role and permissions need to be chosen with that future path in mind.

How Skippr Handles It ​

Skippr gives PostgreSQL teams flexibility without forcing them into a less safe auth pattern. You can keep separate fields for readability or use a single DSN, and in both cases the docs point you toward environment interpolation for the secret-bearing value.

That makes the config easier to review and the secret easier to rotate. You can see which Postgres server and database feed the pipeline without revealing the password that unlocks them.

  • Supports field-based config with password: ${POSTGRES_SOURCE_PASSWORD}.
  • Also supports a full connection_string when teams prefer DSN-based management.
  • Keeps host, port, database, tables, and query reviewable as normal config.
  • Fits both straightforward table reads and future logical-replication CDC setups.

What the First Useful Version Looks Like ​

The first useful version is one Postgres read role, one database, and one table such as public.orders. That proves the credential boundary and the extraction boundary together.

If your team already standardizes on DSNs, use a source-specific environment variable for the full string. If not, keep the endpoint fields visible and hide only the password.