Ask why there are two nearly-identically-named distributed SQL engines with a shared ancestor, and you’ll get an answer rooted in a 2019 governance dispute rather than a genuine technical disagreement. Today, years after that split, Trino and Presto have grown into two projects with real, substantive differences: different governing foundations, different development velocities, and increasingly different architectures under the hood.

If you haven’t read our complete beginner’s guide to Trino or our deep dive into Trino’s architecture, those cover Trino specifically in detail. This piece is about the fork itself: what actually changed, what stayed the same, and which engine makes more sense depending on what you’re building.

Trino vs Presto at a Glance

The Fork, Briefly

The full backstory is covered in more depth in our beginner’s guide to Trino, but the short version matters for understanding everything below. (cite index=”36-1″>In 2019, the original creators of Presto, Martin Traverso, Dain Sundstrom, and David Phillips, departed Facebook due to governance disagreements and forked the Presto codebase. Their new project, originally named PrestoSQL, was rebranded as Trino in December 2020, moving to independent governance under the newly formed Trino Software Foundation.

(cite index=”34-1″>Around the same time, Facebook turned control of the original PrestoDB project over to a new nonprofit, the Presto Foundation, itself part of the Linux Foundation.

(cite index=”32-1″>PrestoDB was subsequently renamed simply to Presto, and PrestoSQL became Trino, which is why the naming still trips people up years later, “Presto” today almost always means the Meta-and-Ahana-steered project, while “Trino” is the independently governed fork.

Governance Is the Root of Every Other Difference

It’s tempting to treat this as a feature-by-feature comparison, but almost every technical difference below traces back to one structural fact: who actually steers each project, and what they’re optimizing for.

(cite index=”43-1″>Trino is maintained by the original creators and a broad open-source community through the Trino Software Foundation. Presto, still commonly called PrestoDB, is maintained primarily by Meta and Ahana and remains production-hardened for Meta-scale infrastructure.

(cite index=”36-1″>Presto’s governance sits with the Presto Foundation under the Linux Foundation, with development tending to be more conservative and slower, focused on stability and production-hardening for large-scale deployments, while Trino has grown a vibrant, rapidly growing community with a faster-paced development cycle introducing new features and optimizations regularly.

That difference in orientation shows up directly in adoption patterns too. Presto’s roadmap has historically tracked what Meta itself needs internally, since Meta remains its largest and most influential user and contributor. Trino’s roadmap, by contrast, answers to a broader coalition of companies, Starburst prominent among them, building a commercial ecosystem around serving a wide range of external customers rather than one company’s internal infrastructure needs.

Development Velocity: A Measurable Gap

This isn’t just a vibes-based claim, independent trackers have quantified it. (cite index=”44-1″>Since the fork, development on Trino has proceeded at roughly three times the velocity of development on Presto. Trino has gained additional connectors not present in Presto, better performance across the majority of shared connectors, expanded SQL support, and is considered much stronger for handling batch ETL/ELT workloads than its counterpart.

That velocity gap compounds over years. A three-times faster development pace sustained since 2019 means Trino hasn’t just added a few extra features, it’s had roughly triple the cumulative engineering time to close gaps, add connectors, and respond to community-reported issues, which is a large part of why Trino has become the more commonly recommended default for new deployments outside of Meta’s own orbit.

Architecture: Where the Two Are Actually Starting to Diverge Technically

For years, the two projects’ internals stayed close enough that migrating a query between them was close to trivial. That’s beginning to change, and it’s the most interesting technical development in this comparison right now.

Trino has stayed entirely on the JVM, investing instead in execution-model improvements within that architecture: (cite index=”43-1″>native task-level fault-tolerant execution, progressively rolled out since version 376, along with large-join spill-to-disk behavior and workload-specific connector optimizations. If you’ve read our architecture deep dive, this is the fault-tolerant execution and dynamic filtering machinery covered there in detail.

Presto has taken a fundamentally different technical bet: rewriting its core evaluation engine in C++. (cite index=”39-1″>The Presto community is moving the evaluation engine from its native Java-based implementation to a new implementation written in C++ using Velox, an effort commonly called Presto C++ or by its development name, Prestissimo. The stated intent is to enable the community to focus on more features and better integration with table formats and other data warehousing systems by moving the evaluation engine into a reusable library.

(cite index=”39-1″>As of the current release, only specific connectors are supported in the Presto C++ evaluation engine, with the Hive connector supporting reads and writes including CTAS, Delta Lake table access through Symlink tables, and DWRF, Parquet, and ORC file format support.

That native engine bet is already paying off in ways that go beyond typical CPU-bound performance tuning. (cite index=”42-1″>Active work is underway bringing GPU acceleration to Presto C++, building on the Velox and NVIDIA cuDF ecosystem. Reference benchmarks on a TPC-H-style workload at scale factor 1,000 showed a GH200 Grace Hopper Superchip completing a full query set in roughly 100 seconds versus about 1,246 seconds on a comparable CPU, a roughly 12x speedup, with multi-GPU configurations using NVLink-based exchange delivering more than 6x additional speedup over a baseline HTTP exchange. Trino has no comparable GPU acceleration initiative underway at this scale, staying committed to its JVM-based execution model instead.

Whether the C++/Velox rewrite or Trino’s JVM-based fault-tolerance investments end up mattering more for your workload depends entirely on what you’re bottlenecked on: raw per-node compute throughput on well-understood file formats favors where Presto C++ is heading, while resilience for long, complex, multi-source federated queries favors the direction Trino has already invested years into.

Fault Tolerance and Batch Workloads

This is one of the more concrete, decision-relevant differences for teams running anything beyond quick interactive queries. Trino’s fault-tolerant execution, covered in full in our architecture guide, lets a cluster retry individual failed tasks rather than restarting an entire query when a worker drops out mid-execution, using an exchange manager to spool intermediate data to external storage like S3.

Presto’s equivalent capability has historically been less mature, a natural consequence of Presto’s stability-first, incremental development pace compared to Trino’s faster iteration cycle. (cite index=”44-1″>Trino is broadly considered much better at handling batch ETL/ELT workloads as a direct result, since long-running batch jobs are exactly the workload profile where the ability to retry a single failed task, rather than an entire multi-hour query, matters most.

If your workload is dominated by long batch or ETL-style queries running for extended periods against potentially unstable infrastructure, this specific gap is worth weighing heavily. If your workload is almost entirely short, interactive queries where a full retry costs seconds rather than hours, the gap matters far less in practice.

Connectors and SQL Support

(cite index=”44-1″>Trino boasts additional connectors that aren’t available in Presto, along with expanded SQL support built up over years of the faster-paced development cycle described above. Presto’s connector list remains capable, and its Hive connector in particular has had enormous engineering investment given Meta’s own reliance on it, but the raw breadth of supported systems favors Trino for teams querying a genuinely diverse mix of data sources, relational databases, streaming platforms, and object storage in open table formats, rather than a Meta-style, Hive-and-HDFS-centric environment.

Both engines remain fundamentally ANSI SQL-compliant and share enough surface-level compatibility that (cite index=”35-1″>migration between them is generally possible, since both are SQL-compliant and share similar syntax, though it’s worth auditing specific connectors, custom functions, and configuration files for compatibility differences before actually switching.

Who Actually Uses Each One

Adoption patterns reflect the governance split almost perfectly. Presto remains deeply embedded at Meta itself, where it originated and continues to be developed against real internal infrastructure demands, alongside other large-scale adopters like Uber and, historically, Twitter, companies whose infrastructure patterns and data lake architectures resemble the environment Presto was originally built to serve.

Trino’s adoption skews toward companies that came to distributed SQL later, or that specifically wanted an engine developed for a broad, external audience rather than tuned primarily around one company’s internal stack, Netflix, LinkedIn, Shopify, and Pinterest are commonly cited examples, alongside its role as the engine underneath Amazon Athena.

Community Size and Momentum

The development-velocity gap described above shows up clearly in raw community metrics too. (cite index=”49-1″>The prestodb/presto repository sits at roughly 17,000 GitHub stars and 5,500 forks, a substantial community by most open-source standards, built up over more than a decade since Presto’s original 2013 release.

Trino’s repository, as covered in our architecture guide, sits at roughly double that figure, around 36,000 stars, despite Trino as a distinct project only existing since the 2019 fork, meaning Trino has accumulated a larger following in roughly a third of the time Presto has been around.

That gap matters in a practical way beyond bragging rights. A larger, faster-growing community tends to mean more third-party connectors, more Stack Overflow answers for obscure error messages, and more consultants and contractors who’ve already solved the specific problem you’re currently debugging. Presto’s community skews more concentrated around large, sophisticated infrastructure teams, Meta’s own scale of operation, rather than the broader long tail of company sizes Trino’s ecosystem has grown to serve.

Cloud-Native and Kubernetes Integration

For teams already running most of their infrastructure on Kubernetes, this is worth calling out as its own decision factor rather than folding it into the general connector-breadth discussion above. (cite index=”31-1″>Trino offers stronger cloud-native integration compared to Presto, alongside its wider connector ecosystem and native task-level fault tolerance, reflecting years of the broader Trino ecosystem, Starburst in particular, investing specifically in Helm charts, operators, and managed cloud offerings aimed at teams running modern containerized infrastructure rather than the more traditional on-premises Hadoop-and-HDFS deployments Presto’s architecture was originally optimized for.

This isn’t to say Presto can’t run on Kubernetes, it can, but the depth of tooling, documentation, and community experience specifically covering that deployment path is measurably thinner than what’s built up around Trino, another downstream consequence of the same development-velocity and community-size gaps covered above.

Licensing: A Non-Issue, For Once

Unlike some of the other comparisons in this space, licensing isn’t a meaningful differentiator here. Both Trino and Presto are licensed under the Apache License 2.0, a permissive, OSI-approved open-source license with no commercial gating or usage restrictions on either side. If you’re coming to this comparison from evaluating something like OpenBao versus HashiCorp Vault, where licensing was the central story, it’s worth knowing this particular fork was never about licensing terms at all, it was purely a governance and control dispute.

When to Choose Trino

Trino tends to be the better choice when:

• You want the faster-moving, more actively developed project, with a substantially larger cumulative feature and connector gap built up since the 2019 fork.
• Your workload includes significant batch ETL/ELT processing where task-level fault tolerance genuinely matters for reliability.
• You’re querying a diverse mix of data sources beyond a Hive-and-HDFS-centric data lake, relational databases, streaming systems, and modern open table formats like Iceberg or Delta Lake.
• You want a project governed independently of any single company’s internal infrastructure priorities.
• You’re already using or considering Amazon Athena and want to understand or extend the engine running underneath it.

When to Choose Presto

Presto remains the better choice when:

• Your infrastructure closely mirrors Meta’s own patterns, heavy Hive Metastore and HDFS usage, and you want an engine developed in that exact environment.
• Raw per-node compute performance on well-supported file formats matters more than the broadest possible connector ecosystem, particularly as the C++/Velox native engine matures.
• You’re interested in GPU-accelerated query execution, an area where active Presto C++ development is meaningfully ahead of anything currently underway on the Trino side.
• You want Ahana’s commercial support specifically, or your organization already has an existing relationship with Meta-aligned tooling and infrastructure.
• Stability and conservative, incremental change matter more to your team than the fastest possible pace of new feature delivery.

Frequently Asked Questions

Are Trino and Presto still compatible with each other? They share enough SQL syntax and architectural DNA that migration between them is generally possible, but it’s not automatic. It’s worth auditing specific connectors, custom functions, and configuration files for compatibility differences before switching, since the two projects have genuinely diverged in supported features since the 2019 fork.

Why do Trino and Presto have such similar names? Trino was originally called PrestoSQL when it forked from the original Presto project (now called PrestoDB, or simply Presto) in 2019. It was renamed Trino in December 2020 specifically to reduce confusion with the original project, though some naming ambiguity persists in older articles and job listings that predate the rename.

Which one is faster? It depends heavily on your workload and which version of each engine you’re comparing. Presto’s ongoing C++/Velox rewrite (Presto C++, also called Prestissimo) is showing substantial raw performance and even GPU-acceleration gains for supported connectors and file formats.

Trino has invested its performance efforts differently, into fault tolerance, dynamic filtering, and broader connector-level optimizations within its existing JVM architecture. Benchmark your actual workload rather than relying on a generic answer either way.

Does Presto support fault-tolerant execution like Trino? Presto has historically had a less mature equivalent to Trino’s native task-level fault-tolerant execution, a consequence of Presto’s slower, stability-focused development pace. This is one of the more concrete reasons Trino is often recommended for long-running batch and ETL workloads specifically.

Is one of them more open source than the other? No, both Trino and Presto are licensed under the Apache License 2.0, a fully permissive, OSI-approved license. The 2019 split between them was driven by a governance and control disagreement, not a licensing dispute.

Which one does Amazon Athena use? Trino, under its earlier PrestoSQL name, powers Amazon’s serverless Athena query service. If you’re already using Athena, you’re effectively running queries against Trino’s engine, managed and abstracted by AWS.

Should I default to Trino for a new project in 2026? For most new deployments outside of a Meta-aligned infrastructure environment, yes, most independent comparisons currently recommend Trino as the default given its broader connector ecosystem, more mature fault tolerance, and significantly faster development pace since the fork. Presto remains a solid, production-hardened choice specifically for teams whose infrastructure closely resembles Meta’s own, or who have a particular interest in Presto C++’s native performance and emerging GPU acceleration work.

Final Verdict

Trino and Presto started as the same project and have spent years since genuinely earning their separate identities. Trino’s independent governance and faster development pace have translated into a broader connector ecosystem, more mature fault tolerance for batch workloads, and status as the more commonly recommended default for teams building a general-purpose federated query layer. Presto’s tighter alignment with Meta’s own infrastructure needs has produced a more conservative, stability-focused release cadence, and its ongoing C++/Velox rewrite is opening up real performance and GPU-acceleration territory that Trino hasn’t pursued.

For the overwhelming majority of teams evaluating this comparison fresh in 2026, without existing Meta-style infrastructure or a specific interest in Presto’s native execution engine, Trino is the more commonly recommended starting point. If you want the deeper technical grounding for why Trino’s architecture behaves the way it does, our Trino architecture deep dive covers the internals referenced throughout this comparison, and Presto’s official documentation is the best place to go deeper on PrestoDB specifically if that’s the direction your evaluation is heading.

For more breakdowns of open-source data infrastructure and DevOps tooling like this one, keep exploring the guides on CourseDrill.