Skippr Docs

Appearance

How to Define PostgreSQL Ingestion Scope Clearly ​

July 2026

PostgreSQL scope becomes clear when the team decides whether the connector is publishing tables or publishing the output of one SQL query, because Skippr treats those as different contracts.

Short Answer ​

Define PostgreSQL ingestion scope with the target database and an explicit choice between tables and query. The source docs make the precedence rule clear: connection_string can override individual connection fields, and query can override tables. That means the reviewable source boundary is not only how Skippr connects, but what it is allowed to expose once connected.

A config that names tables: public.customers,public.orders is a table-level handoff. A config that uses query: SELECT c.id, o.total FROM public.customers c JOIN public.orders o ON ... is a shaped result set. Both are valid, but they are different promises. If the team later enables WAL logical-replication CDC, that later CDC path should still line up with the table-level boundary it decided upfront.

Why Teams Struggle with This ​

PostgreSQL is familiar enough that teams often settle for "the database connection works" and leave the actual extraction boundary fuzzy. That usually means SQL logic sneaks into the connector or a table list quietly widens without anyone noticing.

  • Using connection_string can simplify auth, but it does not answer whether the source contract is tables or SQL.
  • If query is present, it overrides tables, so reviewers should treat that query text as part of the public handoff.
  • A broad Postgres role plus no table decision often creates a larger source surface than the team intended.
  • Logical replication later is easier to reason about when the base table boundary was already explicit.

How Skippr Handles It ​

Skippr keeps PostgreSQL honest by exposing both choices directly. You can connect with discrete fields or one DSN, and then define scope through tables or one query without pretending those are the same thing.

That helps teams stage complexity. Many start with explicit tables because the boundary is easier to defend, then add CDC once the warehouse destination is ready to maintain current state from those tables.

  • Supports field-based config or one PostgreSQL connection string.
  • Lets the source boundary be explicit through tables or one overriding query.
  • Keeps SQL-defined extracts visible instead of implicit.
  • Extends into WAL logical-replication CDC when the upstream setup is ready.

What the First Useful Version Looks Like ​

The first useful version is one PostgreSQL database and one small table list such as public.customers and public.orders. That is enough to validate keys, privileges, and downstream expectations clearly.

If a query already feels necessary, review it like source code and make sure the team agrees that the query output, not the underlying tables, is the thing being published.