Presto vs Trino: Distributed SQL Query Engine Comparison

Overview

Presto was created at Facebook (now Meta) and open-sourced in 2013. It enables SQL queries across multiple heterogeneous data sources — Hive, S3, relational databases, Kafka — using a distributed in-memory query engine. Meta uses Presto internally at massive scale, which has driven significant performance optimizations, and it became the basis for Amazon Athena.

Trino (formerly PrestoSQL) was forked in 2018 by four of Presto's original creators who left Meta. They cited governance concerns — Meta's internal-first development model made it difficult to drive the open-source project forward. Trino has developed faster release cadences, broader SQL coverage, and a stronger commercial ecosystem via Starburst. AWS Athena migrated from Presto to Trino for its v3 engine.

Key Technical Differences

Presto and Trino share the same architectural foundation — they are forks of the same codebase. The fundamental execution model (coordinator, workers, pushdown to data sources) is identical. Performance differences between them are generally minor and workload-dependent rather than systematic. The meaningful differences are in governance, development velocity, and ecosystem momentum.

SQL coverage and standards compliance have diverged, with Trino moving faster toward ANSI SQL compliance and supporting newer features. Connector updates and new data source support also appear in Trino before Presto, particularly for newer formats like Apache Iceberg updates.

AWS's migration of Athena from Presto to Trino (Athena v3) was a significant signal. AWS cited Trino's faster development pace and better SQL standards compliance. This means any team using Amazon Athena v3 is already using Trino, even if they think of it as 'Presto-based.'

Performance & Scale

Both engines perform comparably for equivalent workloads — they share architectural DNA. At very large scale (Meta's internal Presto deployment), Meta's engineering has optimized Presto for their specific workloads. For most organizations, Trino's comparable performance with faster feature development makes it the stronger choice.

When to Choose Each

Choose Trino for new deployments. The faster release cadence, broader SQL coverage, Starburst's commercial support, and AWS Athena v3 alignment make it the more forward-looking choice. Unless you have specific operational or compatibility reasons to stay on Presto, Trino is the better default for new query engine deployments.

Choose Presto if you have an existing Presto deployment that's operating well, if you use specific Presto features that haven't been ported to Trino, or if organizational relationships with Meta's engineering make Presto support more accessible.

Bottom Line

Trino has outpaced Presto in community momentum, development velocity, and commercial ecosystem. For new deployments, Trino is the clear choice. Existing Presto deployments that are functioning well have little urgency to migrate, but new investments should go toward Trino. The AWS Athena v3 migration to Trino validates this direction.