Trino

Trino is a query engine rather than a database — it holds no data of its own and federates across catalogs you configure. AddisDB speaks its HTTP statement protocol, following the paged results through queued and running states until they drain.

Who it is for

Trino lets one query join a Hive table to a Postgres table to a Kafka topic without copying anything. It is the answer to "our data is in six systems and the question spans four of them."

Execution is fully in memory and pipelined between worker nodes, with no intermediate results written to disk. That is what makes it fast for interactive analytics and what makes a huge join fail outright rather than degrade — Trino is a query engine, not a batch system.

Use it for federated analytics across a fragmented data estate, for interactive SQL over a data lake, and as a query layer that saves you from building yet another ETL pipeline.

Set up the server

1. Local: docker run -p 8080:8080 trinodb/trino, which starts with a built-in tpch catalog you can query immediately.
2. Configure catalogs as properties files in etc/catalog/ — one per underlying system.
3. For a secured cluster, note the coordinator host, whether it uses HTTPS, and your credentials.
4. Managed options include Starburst Galaxy and Amazon Athena (which is Presto/Trino under the hood).
5. Confirm which catalogs exist before you start writing SQL — SHOW CATALOGS is the fastest orientation there is.

# A local coordinator with the tpch catalog ready
docker run -p 8080:8080 -d trinodb/trino

Connect from AddisDB

1. New Connection → Trino under Big Data / Warehouse. Port prefills to 8080 and the username to trino.
2. Enter the coordinator host. Trino identifies users by a header, so the username matters even without a password.
3. Set Database to catalog or catalog/schema, for example tpch/sf1.
4. If the cluster requires authentication, paste the password into the API key / token field and set SSL mode to require.
5. Test, then Save.

Password authentication requires HTTPS — Trino refuses to accept credentials over a plaintext connection, so a password with SSL mode off fails before the query is even parsed.

Writing federated SQL

-- Federated: one query, two catalogs
SELECT o.order_id, c.email
FROM hive.sales.orders o
JOIN postgres.public.customers c ON c.id = o.customer_id
WHERE o.created_at > DATE '2026-01-01';

Every table is named in three parts — catalog.schema.table — and that is the whole federation model. What Trino can push down into each connector varies: a predicate on a Postgres table usually becomes a WHERE clause on the remote side, while a join across two catalogs has to pull rows into Trino to execute.

That distinction is the practical one. Filter and aggregate inside each catalog as far as possible, and let the cross-catalog step handle as few rows as you can get away with.

What AddisDB gives you

• The Big Data Console — catalog and schema browser, query pane, and a row cap on previews.
• Cost estimation via EXPLAIN (TYPE IO), showing what the query would read before it reads it.
• Paged results followed to completion, with the query released on the server when you are done with it.
• Full safety: read-only connections, prod tagging, destructive-statement detection.
• The Chart view, notebooks, ⌘K search, and AI querying grounded in your catalogs.
• The Live Monitor over system.runtime.queries, with cancellation wired to kill_query.