How PostgreSQL Defines the Raw Data Contract

July 2026

For PostgreSQL, raw data is the output of the tables or SQL query you point Skippr at, not a vague export of the whole database.

Short Answer

The raw data contract for PostgreSQL is the row shape from the tables you select, or the row shape returned by a custom SQL query if you use query instead of tables. Skippr can connect with explicit host, port, user, password, and database fields or with a full connection string, but the raw layer is still defined by the specific relational surface you choose to expose.

That makes the contract concrete very quickly. Reading public.orders and public.customers says the raw layer is those table rows. Switching to a query that joins orders to a status dimension and selects only five columns changes the contract to that query result. The docs are clear that query overrides tables, so the chosen SQL output is the real boundary once you go that route.

Why Teams Struggle with This

Postgres often feels safe enough that teams blur source discovery and source design together. The result is usually a raw layer that mixes too many tables or hides too much logic inside one query without documenting that the query result is now the promised contract.

• A custom query overrides the table list, so column aliases and filters become part of the raw-data promise.
• If you omit tables, discovery can broaden the contract far past the few entities analysts actually care about.
• WAL logical replication matters for CDC later, but it does not replace the need to define the initial table or query boundary now.
• Host, port, and authentication must be correct, but they are only transport details around the row contract itself.

How Skippr Handles It

Skippr keeps PostgreSQL flexible without making it mysterious. You can connect with field-level settings or a DSN, then choose either named tables or a query. That makes it easier to explain to another engineer exactly what Skippr is reading and why.

The source is also a clean on-ramp to CDC. Once the table contract is stable, the same connector can move toward WAL-based replication without forcing a new story about which records the raw layer represents.

• Supports individual connection fields or a full connection string.
• Can read named tables or a custom SQL query.
• Uses a visible Postgres source surface that is easy to review in config.
• Can extend into WAL logical replication after the batch raw contract is established.

What the First Useful Version Looks Like

The first useful version is one database and a short, explicit table list. That usually tells you whether Postgres is a clean raw source or whether the team should publish a smaller set of views or queries instead.

If a custom query is the right answer, treat that query like an interface. The raw layer is only as stable as the SQL definition that produces it.