Trino (the community fork) has won with faster development, larger community, and richer features. PrestoDB (the Meta fork) is still used at Meta scale. Choose Trino for most use cases; choose PrestoDB only if you're deeply integrated with the Meta ecosystem.
I've run Trino (formerly PrestoSQL) in production for data-lake query workloads and the honest take is: Trino has clearly won the fork war, and for any new project in 2026 Trino is the right choice. Both projects share DNA — they started as Presto at Facebook, forked in 2019 when the original creators left to form the Trino Software Foundation, while Meta continued developing PrestoDB internally. Since the split, Trino has moved faster, added first-class support for modern table formats (Iceberg, Delta Lake, Hudi), and attracted a much larger community. PrestoDB still runs at Meta scale but is less actively developed for external use.
At a team building a data lakehouse on S3 + Iceberg, we evaluated both around 2022. Trino's Iceberg connector was already noticeably more mature — MERGE support, better partition evolution handling, active development. PrestoDB's Iceberg support existed but was missing features. We picked Trino, haven't regretted it. Iceberg support has only grown more important since, and Trino has kept pace.
At a different org already running PrestoDB on EMR for years, we considered migrating to Trino. The migration was moderate effort (SQL dialects are similar but not identical, function names differ in places, some connectors work differently). The payoff was real but not urgent — Trino's features added value but PrestoDB still worked. We migrated over a quarter when we needed better Iceberg support. For legacy PrestoDB users, migration is worth planning; for new deployments, just start with Trino.
Choose Trino if:
query.max-memory and query.max-memory-per-node tuning plus spill-to-disk configuration is essential for production stability.For any new data-lake query engine decision in 2026, use Trino — either self-hosted or via Starburst Galaxy (managed SaaS). The community, features, and momentum all favor Trino. Only stay on PrestoDB if you're already invested and migration cost exceeds benefit. If you're on AWS, Athena is built on Trino (well, originally Presto — AWS has been evolving it) and is a serverless option worth considering for spiky workloads. For lakehouse architectures with Iceberg, Trino + Iceberg is arguably the strongest open-source combination available today, and the Starburst Galaxy managed option removes most operational burden. For organizations already on Snowflake, Databricks, or BigQuery, you likely don't need Trino at all — the warehouse itself handles distributed query; Trino's value appears when you're querying raw lake data directly or federating across heterogeneous sources.
They share the same origin — both started as the Presto project at Facebook in 2012. In 2019, the original creators left Facebook and forked the project, renaming it PrestoSQL and later Trino. Facebook/Meta continued developing its own version under the name PrestoDB under Linux Foundation governance. Seven years after the split, the two projects have diverged significantly in features, community, and ecosystem. They are no longer interchangeable.
Simple SQL queries often work on both (SELECT, JOIN, GROUP BY, common aggregates). But function names diverge (e.g., some date/time functions), connector behavior differs, and newer features (MERGE, row-level updates, newer table formats) exist on Trino but may lag on PrestoDB. Migration between the two is moderate effort — not a pure compile-and-run, but not a ground-up rewrite either. Plan for query testing and occasional rewrites.
Trino, without much hesitation. It has faster development, a larger community (14K+ GitHub stars vs PrestoDB's 16K but slower growth), better support for modern table formats (Iceberg, Delta Lake, Hudi), more managed service options (Starburst Enterprise, Starburst Galaxy, AWS Athena), and a richer ecosystem of third-party tools (dbt-trino, Superset support, DBeaver drivers). PrestoDB remains solid but is no longer the default choice for new distributed SQL deployments.
Starburst was founded by the original Trino creators (same people who forked Presto into Trino in 2019). Starburst offers Starburst Enterprise (self-hosted managed Trino with enterprise features like fine-grained security, caching, and an admin UI) and Starburst Galaxy (fully managed SaaS Trino). Starburst employs many core Trino contributors, so open-source Trino and Starburst's commercial products co-evolve. For teams wanting Trino without operational burden, Starburst is the natural vendor choice.
It can be, but interactive latency depends heavily on cluster sizing, caching, and query patterns. Trino is optimized for analytical queries over large datasets — typical BI dashboards hitting Trino directly see 2–30 second response times depending on data size and complexity. For sub-second BI dashboards, you'll want either result caching (Starburst's Warp Speed or similar), extract-based BI (Tableau Hyper), or a specialized OLAP database (ClickHouse, Druid). Trino is better as a federated query layer than as a sub-second interactive engine.
Athena is AWS's serverless query service built on Presto (originally) and has been evolving toward Trino over time. Athena v3 added Trino compatibility for newer SQL features. For AWS-centric teams that want Trino-like functionality without managing clusters, Athena is the pragmatic choice — pay-per-query, zero infrastructure, S3-native. Trade-off: Athena is a managed black box with less tuning control than self-hosted Trino. For predictable heavy workloads, dedicated Trino clusters are often cheaper; for spiky or ad-hoc workloads, Athena's pay-per-TB-scanned model is attractive.
Yes — Trino has a Snowflake connector that lets you query Snowflake tables through Trino. This is useful for federated queries that join Snowflake data with data in S3/lake, Postgres, or other sources. However, for pure Snowflake workloads, querying through Trino adds unnecessary latency and cost — just use Snowflake directly. Trino's sweet spot with Snowflake is cross-source federation (e.g., joining a Snowflake dimension table with S3/Iceberg fact tables), not routing all Snowflake queries through Trino.