Trino
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.
LicenseOpen source (permissive)· Apache-2.0
DeploymentSelf-hostedManaged
PricingFree
Operational complexityHigh
WorkloadInteractiveBatch
LanguageJava
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
CompareHow Trino answers the questions Query Engines turns on.
Query Engines
| How it works | |
| Engine shape | Distributed cluster: coordinator and workers |
| 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) |
| Running it | |
| 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 |
| Connections | |
| 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 |
| Client access | A JDBC driver, the CLI and official Go, JavaScript, Python and C# libraries; ODBC comes from vendors rather than the project |
| Access | |
| 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 |
Alternatives to Trino
