Skippr Docs

Appearance

How to Manage PostgreSQL Destination Credentials in Skippr ​

July 2026

Keep PostgreSQL destination credentials safe by following the connector model that stores auth in POSTGRES_* environment variables, not in config, while leaving the target database and schema easy to review.

Short Answer ​

Manage PostgreSQL destination credentials in Skippr by following the auth model the docs already prescribe: credentials live in environment variables such as POSTGRES_HOST, POSTGRES_USER, POSTGRES_PASSWORD, and optional overrides like POSTGRES_DATABASE and POSTGRES_SCHEMA, while database and schema stay in config as destination intent.

That is stronger than merely interpolating a password because the destination docs explicitly say credentials are never stored in the config file. It also lines up with the CDC implementation. When you enable CDC, Skippr uses a staging-table plus INSERT ... ON CONFLICT pattern with _skippr_order_token and tombstone tables, so the same env-backed database user needs the documented create and write privileges on the landing area.

Why Teams Struggle with This ​

PostgreSQL destination auth goes off course when teams try to force secrets back into YAML for convenience. That works against the connector design and usually makes it harder to see which values are configuration and which are credentials.

  • Copying host, user, and password into ad hoc local files recreates a config surface the connector deliberately avoids.
  • The destination user can authenticate and still fail if it lacks CREATE, USAGE, or object-write privileges on the target database and schema.
  • Overriding POSTGRES_DATABASE or POSTGRES_SCHEMA silently can confuse operators if the visible config is not kept consistent.
  • SSL mode is operational context and should be set deliberately instead of being left to accidental defaults.

How Skippr Handles It ​

Skippr makes PostgreSQL destination secrets easier to manage because the connector already draws a bright line: auth comes from POSTGRES_* environment variables, and the visible config tells you which database and schema the warehouse should use.

That clarity helps with CDC too. The same destination identity that creates the landing tables can maintain final state through order-token guards and tombstone tracking, so you do not need a separate reconciliation credential.

  • Uses POSTGRES_HOST, POSTGRES_USER, POSTGRES_PASSWORD, and related env vars for auth.
  • Keeps destination database and schema visible and reviewable in config.
  • Supports CDC through a staging-table plus ON CONFLICT final-state pattern.
  • Fits a dedicated warehouse user with create and write privileges limited to the landing area.

What the First Useful Version Looks Like ​

The first useful version is one Postgres warehouse database, one landing schema, and one destination login supplied entirely through environment variables. That proves the connector the way it is actually designed.

If you later need different schemas by environment, keep those targets explicit in config and swap only the environment variables that supply the actual credential.