Trino / Starburst input

Read a table or SQL query from a Trino / Starburst cluster. A Bookmark can read only the rows added or changed since the last successful run.

Category

Input

Connection

Trino / Starburst

What it does

Reads from a Trino / Starburst cluster through a saved Connection and streams the result into the pipeline in batches. Trino queries many underlying systems through one endpoint, so one node can read a lakehouse table, a relational database, or a join across both. Pick a table with the live catalog, schema and table browser, or write your own SQL.

Inputs and outputs

When to use it

• Query data across many sources through one Trino cluster
• Read a table straight from a lakehouse catalog (Hive, Iceberg, Delta)
• Push filtering, joins and aggregation down to Trino, where they run faster

Examples

hive.sales.orders

SELECT region, SUM(total) FROM hive.sales.orders GROUP BY region

SELECT * FROM hive.s.a JOIN postgresql.public.b USING (id)

SELECT * FROM iceberg.sales.orders WHERE order_date >= DATE '2026-08-01'

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

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.
• The query is Trino SQL, the cluster'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 Trino to describe the statement's output, which runs nothing.
• The browser needs a Connection; a local Trino is usually http on 8080, Starburst Galaxy https on 443.
• Numbers and booleans come across natively; decimals, dates and timestamps arrive as text. Cast in SQL if you need them typed on the canvas.
• Timestamps keep their full precision. A microsecond timestamp is not silently rounded to milliseconds on the way out.
• A table name can be given bare or partly qualified, and the connection's default catalog and schema fill in the rest.
• A query that returns no rows still passes its columns downstream, so a Union or Join below it keeps working.
• 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.

Related nodes