Trino
420+Summary
Distributed SQL query engine that federates queries across multiple data sources (S3/Parquet, PostgreSQL, MySQL, Hive, Kafka, MongoDB, Iceberg, Delta Lake) in a single SQL query: enabling ad-hoc analytics on data lake storage without moving data to a centralized warehouse.
Primary Use Case
Interactive analytics on data stored in S3, HDFS, or object storage in columnar formats (Parquet, ORC); federated queries across heterogeneous data sources; replacing Presto/Hive for data platform analytics workloads.
Consistency & Transactions
Scaling
Read scalability
Coordinator-worker architecture. Workers process query fragments in parallel. Adding workers increases query throughput and maximum data scan volume. Scales from 4 nodes to thousands; queries decomposed into stages that execute across all workers.
Write scalability
Trino supports INSERT into object storage (Iceberg, Delta Lake, Hive) but is not optimized for high-throughput writes. Writes are executed as scan-and-insert operations, not streaming ingestion. Primary use case is read-heavy analytics.
Failure Behavior
Known failure modes
- ·Worker OOM on queries that exceed in-memory hash join limit: enable spill to disk
- ·Coordinator is a single point of failure: no HA coordinator in open source Trino
- ·S3 throttling under heavy parallel scan workloads: use request throttling and prefix distribution
- ·Long-running queries hold worker memory; concurrent queries may starve if resource groups not configured
Degradation patterns
- ·Unpartitioned large tables cause full scans: partition by date or commonly-filtered columns
- ·Small files on S3 cause overhead from many metadata operations: compact to 128MB+ Parquet files
- ·Network egress cost from S3 to Trino workers in a different region adds latency and cost
Recovery considerations
- ·Query failure: Trino retries individual query stages on transient failures; full query restart on persistent failure
- ·Worker failure: coordinator reassigns failed stage to a healthy worker
- ·No persistent state in Trino workers: stateless and replaceable
Architecture Guidance
Common topology roles
Migration notes
- ·Trino replaces Presto with active development and broader connector ecosystem; Presto and Trino diverged after the Presto Foundation fork: evaluate connector coverage before migrating
- ·Apache Spark SQL is the common alternative: choose Trino for interactive sub-30s analytics latency, Spark for complex transformations and ML workflow integration
- ·ClickHouse is preferred over Trino when low-latency analytics on a single columnar data store is the goal and federation across heterogeneous sources is not required
Advisor Guidance
When: scenario has analytics_pipeline with data in S3 object storage
Trino provides a SQL interface to S3 Parquet data without a separate data warehouse; consider for interactive analytics on the data lake
When: scenario needs to join production database data with historical S3 data
Trino's federated query capability allows a single SQL query across PostgreSQL and S3: use with read replica for the database source to avoid production impact
Comparison Factors
operational complexity
Medium: cluster deployment; managed options (AWS Athena, Starburst) reduce ops
latency
Seconds to minutes: appropriate for analytics, not real-time queries
durability
Not a storage system: data durability is the responsibility of the underlying storage
cost
Open source compute; primary cost is worker instance and S3 data transfer
Basis
Trino (formerly PrestoSQL) is a production-grade query engine with extensive documentation and adoption at Meta, LinkedIn, Netflix, and Lyft; performance characteristics are documented in benchmarks and engineering blog posts
Related Architecture Knowledge
Outbound: this entity affects
Trino is used for federated queries across heterogeneous data sources; ClickHouse provides faster single-store analytics when all data can be consolidated. Organizations often use both: Trino for cross-source joins, ClickHouse for high-frequency dashboard queries.
Full relationship →Trino can query Iceberg and Delta Lake materialized views defined over object storage, enabling low-latency analytics against pre-aggregated data without a separate data warehouse.
Full relationship →