Postgres input

Read the result of a SQL query from PostgreSQL. A Bookmark can read only the rows added or changed since the last successful run.

Category: Input
Connection: PostgreSQL

What it does

Reads from a PostgreSQL database through a saved Connection and streams the result into the pipeline in batches. Pick a table with the live schema and table browser, or write your own SQL when you want Postgres to filter, join or aggregate before the rows move. Credentials live on the Connection, never in the pipeline.

Inputs and outputs

Inputs	None. This node starts a pipeline.
Outputs	One.

When to use it

Pull a table or query result out of Postgres
Push filtering, joins and aggregation down to the database, where they run faster
Move application data into a warehouse, a file, or a lakehouse table

Examples

Pick a table

public.orders

The browser lists the real schemas and tables the connection can see.

Only the rows you need

SELECT id, name, total FROM orders WHERE status = 'paid'

Far cheaper than reading the table and filtering on the canvas.

Aggregate at the source

SELECT region, SUM(total) FROM orders GROUP BY region

Moves a summary out instead of every row.

Join before it leaves

SELECT o.*, c.name FROM orders o JOIN customers c ON c.id = o.customer_id

One trip instead of two reads and a Join node.

Only rows newer than the last successful run

Bookmark column: updated_at · Start from: 2026-01-01 00:00:00

Each Live run reads only rows added or changed since the last run that succeeded. After an outage, one run catches up.

Tips

Press ⤢ beside SQL query for the SQL Studio: a full-screen editor that browses the connection's schemas, tables and columns, shows the columns your query returns without running it, and runs it with Run to here without closing.
Pre-SQL runs on this same connection immediately before the query, so session settings stick: SET search_path, SET statement_timeout, or a procedure that prepares the extract. It also runs when you press Test, because a test run really does read from the database, so keep it to session setup.
The query is Postgres SQL, the source's own dialect. This is a source query, not a Trinium row expression.
Columns appear as soon as you pick a table or write a query, with no test run needed. Trinium asks Postgres to describe the statement, which reads no rows and costs nothing.
A query WINS whenever both a table and a query are filled in, so clear the query to go back to reading the table.
Dates, times and timestamps come across as real dates, so you can sort, filter and do date math on them straight away. NUMERIC and uuid arrive as exact text; retype NUMERIC with Manage Columns if you want a fixed decimal.
A query that returns no rows still passes its columns downstream, so a Union or Join below it keeps working.
Pick a Connection first; add one on the Connections page if the list is empty.
Bookmark: each Live run reads only the rows whose bookmark column is past where the last SUCCESSFUL run stopped. A failed or cancelled run never moves it, so after an outage one run reads everything that was missed. Staging and Production keep their own; a Test run always reads from Start from and never moves it.
The bookmark column must move forward whenever a row is added or changed: an updated_at stamp, or an ever-increasing id. A row whose bookmark column is empty is never read, and a row DELETED in the database is never seen, so reload the table now and then if deletes matter.
With a hand-written query, write WHERE updated_at >= ${bookmark} where the value goes. Editing the table, query, connection or column keeps the bookmark, and the run's Messages say when it last read something else. A Bookmark column of another kind (a date where it was a number) is refused until you Set or Reset it in the node's Bookmark panel.
Each value of a text parameter the pipeline uses keeps its own bookmark, so region = EU and region = US each read only their own new rows. A number or true/false parameter in the table name is refused, because one bookmark would serve every value; make it a text parameter with a list of choices. A date in the table name (events_${date:%Y%m%d}) carries the bookmark into each new day's table, so bookmark a date-time column there.
When the pipeline uses a text parameter anywhere, such as ${region} in this query or in a Filter after it, each value keeps its own bookmark, so a run for one region never moves another's. A value's first run reads from Start from, and date, number and true/false parameters share one bookmark. Starting or stopping using a text parameter pauses the bookmark the same way, until you Set where the value starts or Reset the old bookmark.
Lookback (date-time columns only) re-reads the N minutes before where the last successful run stopped, to catch rows a long transaction committed late. A first run and every Test run read exactly from Start from. Re-read rows load again, so use it with an Upsert output.