# Trino

> Distributed SQL query engine for federated analytics

Trino is an open-source distributed SQL engine that queries data where it lives — object storage, lakehouse table formats, and operational databases — through a single interface.

Website: https://trino.io

## Use it when

- Data lives in several systems (lake, warehouses, operational databases) and one SQL query should join across them without copying anything first.
- You are building a lakehouse on Iceberg or Delta and want an interactive engine that owns no storage.
- BI workloads should be served off the lake without a warehouse load in between.
- You have a platform team to run it; resource groups, access control, and fault-tolerant execution are all there to be configured.

## Think twice when

- Nobody wants to operate a JVM cluster; Athena and Starburst Galaxy sell this engine's capability without the ops.
- Latency targets are sub-second at high concurrency; a serving OLAP store like ClickHouse or Pinot fits that shape better.
- The work is long, heavy batch; fault-tolerant execution helps, but Spark's recovery model was built for it.

## How it runs

Self-hosted as a coordinator and workers, typically on Kubernetes, with a Hive, Glue, or REST catalog behind the lake connectors. Forty-three connectors federate sources; opt-in fault-tolerant execution spools exchanges to object storage so a lost worker does not kill the query. Clients connect over JDBC, the CLI, and official Go, Python, JavaScript, and C# libraries.

## Details

### General

| Attribute | Value |
| --- | --- |
| License | Open source (permissive) |
| SPDX identifier | Apache-2.0 |
| Deployment | Self-hosted, Managed |
| Workload | Interactive, Batch |
| Operational complexity | High |
| Pricing | Free |
| Language | Java |
| Repository | https://github.com/trinodb/trino |
| Documentation | https://trino.io/docs/current/ |
| Stars | 13.3k |

### Query Engines

| Attribute | Value |
| --- | --- |
| Engine shape | Distributed cluster: coordinator and workers |
| Non-lake sources | 43 connectors in 483 (Postgres, MySQL, Oracle, SQL Server, MariaDB, MongoDB, Cassandra, Kafka, Elasticsearch, OpenSearch, Druid, Pinot, Exasol, BigQuery, Redshift, Snowflake, Prometheus, even DuckDB) and one query joins across them |
| Table formats | Hive formats (ORC, Parquet, Avro) plus Iceberg and Delta read and write; Hudi is read-only |
| Catalog required | Hive Thrift metastore or Glue for the Hive and Delta connectors; Iceberg adds REST, JDBC, Nessie and Snowflake catalogs |
| SQL dialect | Trino SQL (ANSI-based) |
| Client access | A JDBC driver, the CLI and official Go, JavaScript, Python and C# libraries; ODBC comes from vendors rather than the project |
| Concurrent users | Resource groups queue rather than fail, selectors match user, source, query type or client tag, with hard and soft limits on concurrency, memory and CPU |
| Acceleration | File system caching on local disk through Alluxio libraries for the Hive, Iceberg and Delta connectors, plus metastore caching, off by default |
| Failure recovery | Fault-tolerant execution, off by default, QUERY or TASK retry, with TASK spooling exchanges to S3, Azure Blob, GCS or HDFS so a lost worker does not kill the query |
| Access control | System access control built in, allow-all, read-only, file-based rules, and Open Policy Agent or Apache Ranger, applied before connector checks |

## Capabilities

- [Query Engines](https://matca.io/capabilities/query-engine)

---

Source: https://matca.io/trino
Last updated: 2026-08-31T11:40:47.888Z