Trino / Starburst output

Load rows into a Trino / Starburst table (append or truncate; auto-creates). Turn on All or nothing and an append that fails leaves the table as it was.

Category

Output

Connection

Trino / Starburst

What it does

Loads the incoming rows into a table on a Trino / Starburst cluster through a saved Connection, which in practice usually means writing into a lakehouse table (Iceberg, Delta or Hive). Add the rows to what's already there, or empty the table and reload it. If the target table doesn't exist it is created from the incoming columns.

Inputs and outputs

When to use it

• Write pipeline output into a lakehouse table
• Refresh a table completely on every run
• Land results in any catalog Trino is allowed to write to

Examples

Pre-SQL: TRUNCATE TABLE hive.sales.stg_orders · Post-SQL: MERGE INTO hive.sales.orders t USING hive.sales.stg_orders s ON t.id = s.id WHEN MATCHED THEN UPDATE SET total = s.total

Table: hive.sales.orders · Mode: append

Mode: truncate

Table: iceberg.analytics.daily_sales

Batch size: 200

Tips

• Each pre- and post-SQL statement has its own ⤢, the SQL Studio, with the connection's tables and columns beside the statement. It has no Run button: a Test run executes none of these statements.
• Pre-SQL and post-SQL run on this same connection, around the load. Pre-SQL runs and commits BEFORE the load starts; post-SQL runs only AFTER it has finished successfully, so a failed load never fires the merge.
• One statement per row, run in order. If one fails the run stops there, and the message names which statement it was and what the database said.
• A Test run (Run to here) executes none of them, so testing stays safe on a pipeline whose pre-SQL truncates a table.
• The target catalog's connector has to support writes. Iceberg, Delta and Hive do; plenty of read-only catalogs don't.
• There is no upsert: Trino has no ON CONFLICT. Use append, or truncate for a full refresh.
• Truncate empties the table with TRUNCATE TABLE, falling back to DELETE FROM if the connector or your grants don't allow it. If both fail the run stops and names the table rather than loading on top of stale rows.
• Dates, times and decimals load natively, with their fractional-second precision stated so a microsecond timestamp isn't rounded to milliseconds.
• All or nothing (off by default, append only): on, rows load into a staging table beside the target and ONE INSERT … SELECT copies them in at the end, so a failure leaves the target as it was. It needs CREATE TABLE in that schema. Off, rows go straight in and a failure part-way leaves the rows written so far. Truncate has no all-or-nothing form in Trino.
• Rows are sent in batches, and a batch is flushed on total size as well as row count, so a table with a wide text column sends smaller batches on its own, without you lowering Batch size.
• A Test run writes nothing to the cluster, so you can press Test as often as you like.

Related nodes