What are Trino and Presto, and what is the difference?

Trino and Presto are two distributed SQL query engines, born from the same project, that run MPP (massively parallel processing) queries directly on data that stays where it lives, without first loading it into a proprietary database. The principle is the separation of compute from storage: the engine connects through connectors to heterogeneous sources, a data lake on object storage, a data warehouse, a transactional database, even a file system, and distributes query execution across multiple nodes in memory, in parallel. The practical result is the ability to write a single SQL query joining rows from different systems, without intermediate copy pipelines. It is the same principle as data virtualization, applied here with a compute engine built for analysis over large volumes rather than point-in-time access to a single record. On a data lakehouse built with an open table format, Trino or Presto is often the query engine that exploits those transactional guarantees without tying itself to a proprietary platform.

See also: Data Virtualization · A technique that queries data across multiple sources as one, without copying it: a middle layer translates the query in real time.

Genealogy: why one project has two names

Presto originated at Facebook in 2012, the work of four engineers, Martin Traverso, Dain Sundstrom, David Phillips and Eric Hwang, as a replacement for Apache Hive for interactive queries over massive data volumes; Facebook open-sourced it in November 2013. In January 2019 the four founders left Facebook and forked the codebase, founding the Presto Software Foundation as an independent non-profit: the fork was initially named PrestoSQL, same code, same team, different governance, in response to late-2018 policy changes that gave Facebook committers greater privilege over the open-source community. In September 2019 Facebook transferred PrestoDB to the Linux Foundation, which also applied for and received the trademark on the name "Presto": neither the original creators nor the top contributors were invited into that foundation. After extended negotiations between the two communities, the PrestoSQL team was forced to rename: on December 27, 2020, PrestoSQL officially became Trino. Community, codebase and leadership stayed the same, only the name changed. Today Trino, led by the original creators through the Trino Software Foundation, moves at a markedly faster development pace; PrestoDB remains hosted by the Linux Foundation, with Meta and IBM, which acquired Ahana in 2023, among its main contributors. In enterprise practice, when people say "Presto" today they often actually mean Trino, and that is the first thing worth verifying before choosing which one to adopt or cite in a request for proposal.

An enterprise example

A retail group with a data lake on S3 in Iceberg format, a cloud data warehouse for financial reporting, and an operational database for inventory can put a Trino cluster in front of all three sources: analysts write a single SQL query joining historical sales from the lake with real-time stock from the operational database, without waiting for a nightly ETL pipeline to copy inventory into the warehouse. Compute cost stays separate from storage, Trino nodes scale with query load rather than data volume, which stays put in each respective source.

When to choose it, when not to

Trino or Presto make sense when you need to query heterogeneous sources with federated SQL without moving the data, when the use case is exploratory analytics over large volumes on a data lakehouse, or when you need a vendor-neutral query layer on top of open table formats without tying yourself to a proprietary engine. They are not the right choice for transactional workloads, they do not handle high-frequency concurrent writes the way an OLTP database does, nor for heavy, recurring batch transformations, where a data processing engine like Spark, tuned for long jobs and massive shuffles, remains more efficient. Use them with caution for dashboards with high user concurrency on repeated, low-latency queries too: every query starts fresh from the original sources, and hundreds of simultaneous users can saturate the source systems well before a pre-aggregated table in a dedicated warehouse would. In those cases the better alternatives are a traditional cloud data warehouse, a semantic layer with caching in front of recurring queries, or a combination of the two.