query engine

Trino

Trino is a distributed SQL query engine for data in many places. This profile covers what it does, how it is operated, and where it stops being the right choice.

What the product actually does

Trino answers SQL questions by pushing work down to the systems that hold the data and combining the results. A single query can join a table in Postgres to a table in S3 to a table in Kafka, and the engine handles the federation.

It holds no data itself. That makes it cheap to add and means the query cost lands on the sources, which is either exactly what you want or a problem you discover when a dashboard starts hammering production.

How it is operated and what it costs

Trino is open source and free. The cost is a cluster of workers, and the sizing decision is memory per worker against the largest join the workload will attempt. A query that exceeds the memory limit fails rather than spilling gracefully in every case.

Managed Trino exists from several vendors and prices on compute. The decision is usually whether the team wants to run a coordinator and worker pool or pay someone else to.

Where it breaks down

Concurrency. Trino is built for a small number of large analytical queries. Hundreds of small dashboard queries against one cluster produce queueing, and the usual answer is a second cluster or a caching layer.

Federation is a feature and a trap. A query that joins across four systems is convenient and also has four failure modes and no shared statistics, so the optimiser is guessing.

What switching costs

Low. SQL is standard and the connectors are configuration. The cluster tuning knowledge is what a team accumulates and loses.

Sources

Trino public documentation, read October 2026.