What Access Skippr Needs to Write to PostgreSQL

June 2026

PostgreSQL write access is concrete: the user needs the right database and schema privileges, not just a password that works.

Short Answer

Skippr needs PostgreSQL connection credentials through the normal environment variables such as POSTGRES_HOST, POSTGRES_USER, and POSTGRES_PASSWORD, plus concrete database privileges. The destination docs spell those out: CREATE on the target database for silver or gold schema creation, USAGE and CREATE on the target schema, and the ability to create tables and insert data.

That means a working password alone is not enough. A user writing into database analytics and schema raw has to be able to build the objects Skippr manages there, and when CDC is enabled PostgreSQL also needs to support the staging-table plus INSERT ... ON CONFLICT merge pattern that keeps only newer _skippr_order_token values.

Why Teams Struggle with This

Postgres warehouse issues are usually privilege-shape issues, not connectivity issues. The login can succeed and the database can exist, but the role may still be unable to create the tables or schemas that the first useful load depends on.

• The database user needs CREATE on the target database if Skippr will create downstream schemas.
• The same user needs USAGE and CREATE on the target schema where raw tables land.
• Ability to create tables and insert data is mandatory because the destination owns real managed objects, not just transient queries.
• CDC relies on a staging-plus-merge pattern, so the role has to support the table updates that final-state reconciliation performs.

How Skippr Handles It

Skippr keeps PostgreSQL destination access easy to audit because credentials stay in the standard environment variables and the config only names the database and schema. That lets database owners reason in native Postgres terms instead of mapping custom warehouse roles back to actual grants later.

The CDC destination docs make the write behavior equally clear. PostgreSQL uses a staging table plus INSERT ... ON CONFLICT with newer-token checks and tombstone tracking, so the role is being granted the ability to maintain current-state tables deliberately, not to run uncontrolled DML.

• Uses environment-based PostgreSQL credentials rather than storing secrets in config.
• Needs CREATE on the database plus USAGE and CREATE on the target schema.
• Maintains final-state CDC tables through staging and INSERT ... ON CONFLICT.
• Automatically adds _skippr_order_token columns and companion tombstone tables.

What the First Useful Version Looks Like

The first useful version is one database, one dedicated schema such as raw, and one Postgres role that can create and update only what Skippr is meant to own there.

Once that works, you can add more sources, but keep the grant model explicit so later schema creation does not fail halfway through a warehouse rollout.