What Is Presto SQL? Distributed Queries Explained

Presto is a distributed SQL query engine: it runs standard SQL across a cluster of machines against data that lives somewhere else — data lakes on S3, Hive tables, Kafka topics, even ordinary MySQL databases. Born at Facebook in 2012 to replace slow Hive batch jobs with interactive queries, it's the engine behind Amazon Athena and the ancestor of Trino.

How is a query engine different from a database?

A database like PostgreSQL owns both halves of the job: it stores your data on its own disks and executes queries against that storage. Presto deliberately does only the second half. It stores nothing — every table it queries belongs to some external system, accessed through a plug-in called a connector. That separation of storage and compute is the defining idea.

The practical consequences: you can point Presto at petabytes of Parquet files on S3 without loading anything, you can scale query horsepower up and down independently of the data, and — because connectors are just plugins — one SQL statement can join tables from entirely different systems. The trade-off is that Presto has no indexes, no transactions of its own, and no control over how the underlying data is laid out.

How does the coordinator and worker architecture work?

A Presto cluster has one coordinator and many workers. The coordinator is the brain: it parses your SQL, builds a distributed plan, and breaks the work into small units called splits. Workers are the muscle: each one grabs splits, reads its slice of the data through the connector, and processes rows in memory, streaming intermediate results to other workers through the stages of the plan.

In plain words: ask for a sum over a billion rows, and the coordinator hands a few thousand file chunks to fifty workers, each worker sums its chunks in parallel, and a final stage adds up fifty partial sums. Everything happens in memory with pipelined execution — no writing intermediate results to disk between steps, which is why Presto answers in seconds where classic MapReduce-era Hive took minutes.

-- You write ordinary SQL; the distribution is invisible
SELECT region, COUNT(*) AS orders, SUM(amount) AS revenue
FROM s3_lake.sales.orders          -- Parquet files on S3
WHERE order_date >= DATE '2026-01-01'
GROUP BY region
ORDER BY revenue DESC;

What is the difference between Presto and Trino?

Same engine, forked community. The four original creators left Facebook in 2018 and continued their fork as "PrestoSQL", while Facebook kept "PrestoDB" and donated it to the Linux Foundation's Presto Foundation. After a 2020 trademark dispute, the creators' fork renamed itself Trino. Today Trino is the more actively developed line and the one most new deployments choose; PrestoDB continues under the Presto Foundation, used heavily at Meta, Uber, and via Ahana/IBM.

For a query author the dialects remain very close — most SQL runs on both. See our tool profiles of Presto and Trino for a feature-by-feature comparison and which fork fits which situation.

Where can you run Presto?

You rarely install it by hand. The common homes, roughly in order of effort: Amazon Athena is fully serverless — point it at S3, pay per terabyte scanned, never see a cluster. Amazon EMR runs managed Presto/Trino clusters you size yourself, cheaper at sustained heavy use. Starburst (founded by Trino's creators) sells an enterprise distribution with security, autoscaling, and extra connectors, as SaaS (Starburst Galaxy) or self-managed. And plain open-source Trino on Kubernetes is free and popular for teams comfortable operating their own infrastructure.

Option	Ops burden	Best for
Amazon Athena	None (serverless)	Ad-hoc queries on S3, spiky workloads
Amazon EMR	Medium	Sustained heavy usage on AWS
Starburst	Low–medium	Enterprise security, support, many connectors
Open-source Trino	High	Full control, no license cost

What does a federated query look like?

Federation is Presto's party trick: because every data source is just a catalog, a single query can join across systems. Table names take the form catalog.schema.table, and the engine pushes work down to each source where it can.

-- Join live MySQL orders against historical Parquet on S3
SELECT
    c.customer_name,
    l.lifetime_orders,
    r.orders_this_week
FROM mysql.crm.customers AS c
JOIN hive.lake.customer_lifetime AS l      -- S3 / Parquet
    ON l.customer_id = c.customer_id
JOIN (
    SELECT customer_id, COUNT(*) AS orders_this_week
    FROM mysql.shop.orders
    WHERE created_at >= current_date - INTERVAL '7' DAY
    GROUP BY customer_id
) AS r
    ON r.customer_id = c.customer_id;

No ETL job, no copying MySQL into the lake first — the join happens inside the engine. That makes federation superb for exploration and one-off analysis, though for dashboards hit thousands of times a day you'd still materialize the result rather than re-federate on every load.

When should you use Presto — and when not?

Reach for Presto/Trino when you need interactive SQL over data-lake files, when data is spread across systems you don't want to consolidate, or when analysts need one SQL front door to everything. Skip it for transactional workloads (no OLTP, no row-level updates in the classic sense), for sub-100ms serving queries behind an application, and for cases where a single-node PostgreSQL comfortably fits the data — a distributed engine's coordination overhead only pays off at scale.