Trino

A distributed SQL engine that queries data where it lives, from Iceberg tables on S3 to a live PostgreSQL database, in one query.

What it is: Query engines
Type: Open source
Made by: Trino Software Foundation
License: Apache 2.0
Facts checked: 5 October 2026

What it is

A Trino cluster has one coordinator and many workers. The coordinator parses and plans each query and splits it into stages. Workers pull data through connectors and stream intermediate results to each other in memory, stage to stage, rather than writing them to disk in between. That makes Trino good at interactive queries that finish in seconds over large tables.

Each catalog is a connector: Iceberg, Delta Lake, Hive and Hudi for lake tables, plus PostgreSQL, MySQL, Kafka, MongoDB, BigQuery and many more, so one query can join an Iceberg table with a live PostgreSQL table. Presto’s creators built the original at Facebook in 2012, left in 2018 to continue it as PrestoSQL, and renamed it Trino in December 2020. Amazon Athena’s current engine is built from Trino.

Why teams pick it

Federation: join lake tables with operational databases without copying either
Reads and writes Iceberg and Delta Lake tables, including UPDATE, DELETE and MERGE
ANSI SQL and more than 35 connectors
Apache 2.0, with managed versions such as Amazon Athena, Amazon EMR and Starburst

Watch out for

A long-running cluster to size and operate; by default a query fails if a node runs out of resources, unless you turn on fault-tolerant execution
No storage of its own, so speed depends on file layout, partitioning and table statistics
Hudi support is read-only, and merge-on-read tables are seen only as of their last compaction
Iceberg v3 support is experimental, without row-level updates or deletes on v3 tables

Alternatives

What all query engines have in common →

Amazon AthenaAWSAWS’s serverless SQL engine for data in S3: no cluster to run, and on-demand queries cost $5 per TB scanned.

Apache Arrow AceroExperimentalOpen sourceThe streaming execution engine inside Arrow’s C++ library: you hand it an exact plan of nodes (scan, filter, project, aggregate, join, sort) and it streams Arrow record batches through them, with no SQL parser or optimizer of its own.

Apache CalciteOpen sourceA Java framework with everything a database needs to understand a query (SQL parser, validator, relational algebra and a rule-based, cost-based optimizer) but no storage of its own, which Hive, Flink, Druid, Dremio, Beam and many other systems embed as their SQL front end and planner.

Apache DataFusionOpen sourceA query engine library in Rust, built on Arrow, that other projects embed and extend to build their own databases and data tools.+1 Apache DataFusion Comet

Apache HadoopOpen sourceThe project that made big-data clusters normal: a distributed file system (HDFS), a cluster scheduler (YARN) and the MapReduce engine.

Apache HiveOpen sourceThe first SQL engine for Hadoop, and the source of the Hive Metastore, the table catalog that Trino, Spark, Impala and Flink still read.Apache ImpalaOpen sourceAn MPP SQL engine in C++ for interactive queries over Hive tables on HDFS, Kudu, Iceberg and object storage; built and mainly sold by Cloudera.Apache PigDormantOpen sourceA step-by-step scripting language, Pig Latin, that compiles to MapReduce, Tez or Spark jobs on Hadoop. Still released, but the project calls itself dormant.

Apache SparkOpen sourceThe general-purpose distributed engine for large batch jobs, streaming and machine learning, in Python, SQL, Scala, Java or R.

Apache ZeppelinOpen sourceA self-hosted web notebook where each paragraph runs through an interpreter: Spark, Flink, JDBC, Python and more. Maintained, but behind Jupyter and Databricks in reach.

chDBOpen sourceThe ClickHouse engine packaged as a library: run ClickHouse SQL inside a Python, Go, Rust or Node.js program, with no server.

Cloudflare Basin SQLRenamedCommercialCloudflare’s serverless, distributed SQL engine for Apache Iceberg tables in Basin Catalog on R2, called R2 SQL until it became generally available on 1 October 2026, billed by the data it scans.

DuckDBOpen sourceAn in-process analytical SQL database: a library with no server that queries Parquet, CSV, Iceberg and S3 directly.

GizmoSQLOpen sourceA database server that wraps DuckDB (or SQLite) and serves it to many clients over Arrow Flight SQL, with TLS and authentication.

GlareDBDormantOpen sourceA small, embeddable SQL engine in Rust for querying Parquet and CSV files locally, over HTTP or in S3 and GCS, from a CLI, Python or the browser. It began as a DataFusion-based federated query service and was rewritten in 2025 on its own engine, and it has had no release since June 2025.

HotdataCommercialA managed SQL engine for AI agents, built in Rust on Apache DataFusion and Arrow: each agent gets short-lived “instant databases” to load data into, then runs read-only SQL, vector, full-text and geospatial queries over an HTTP API or CLI.

IbisOpen sourceA Python dataframe API that compiles to SQL, so the same code runs on DuckDB on a laptop and on BigQuery, Snowflake, PostgreSQL or more than 20 other engines.

PolarsOpen sourceA DataFrame library with a Rust query engine underneath: you write Python (or Rust, SQL, Node.js, R) and it plans, optimises and runs the query on every core, streaming data bigger than memory.

Presto (PrestoDB)Open sourceFacebook’s distributed SQL engine, now governed by the Linux Foundation, moving its workers from Java to C++ on Velox. Trino is its 2019 fork.

RayforceOpen sourceA small embeddable engine in pure C that runs columnar analytics, graph traversals and recursive Datalog queries in one optimised plan.

Spice.ai OSSOpen sourceA single-binary SQL engine in Rust, built on DataFusion and Arrow, that federates queries across databases, warehouses and lakes, keeps hot datasets in a local accelerated copy, and adds search and LLM APIs on top.

VeloxOpen sourceMeta’s open-source C++ execution engine library: it takes an already-optimized query plan and runs it with vectorized operators, and it is the engine inside Presto’s C++ workers (Prestissimo) and Apache Gluten’s native Spark.

How it fits with other technologies

What Trino uses

What uses Trino

One query across an Iceberg catalog and a PostgreSQL catalog · sql

-- catalog "lake": connector.name=iceberg, iceberg.catalog.type=rest
-- catalog "app":  connector.name=postgresql
SELECT c.segment, sum(o.amount) AS revenue
FROM lake.sales.orders AS o
JOIN app.public.customers AS c ON c.id = o.customer_id
WHERE o.ts >= TIMESTAMP '2026-09-01 00:00:00'
GROUP BY c.segment
ORDER BY revenue DESC;

-- the same table as it was a week ago
SELECT count(*) FROM lake.sales.orders FOR TIMESTAMP AS OF current_timestamp - INTERVAL '7' DAY;

See it in a real stack

Open lakehouse on Iceberg →

Live modeldata or requestresponsebusy / idle instance

Open in playground

What you’re watchingServices publish order events to Kafka. Spark reads them in micro-batches and commits them to an Iceberg table whose files live on S3. Dashboard queries run on Trino, which reads the same table.

Benchmarks

Benchmark · ClickHouse Inc.ClickBenchHow fast analytical databases run 43 SQL queries over one 100-million-row table of web analytics events, on the same cloud machines.Includes Trino · 7 caveats to read first

How to read a benchmark →

Where it came from2012–2026

By 2012, Facebook’s data warehouse held more than 300 petabytes in Hadoop, and analysts queried it through Hive. Hive turned each SQL query into MapReduce jobs, which were designed for large-scale, reliable computation and optimised for overall throughput, with every stage writing to disk. At that scale Facebook needed an interactive system optimised for low query latency.

In fall 2012, Martin Traverso, Dain Sundstrom, David Phillips and Eric Hwang, on Facebook’s Data Infrastructure team, set out to build that system, and they wanted it open source from the start. Presto went into production in early 2013 and was open-sourced that November. By then it ran more than 30,000 queries a day, scanning a petabyte, and Facebook reported it was 10x better than Hive/MapReduce in CPU efficiency and latency. Uber, Netflix and Airbnb adopted it, and Amazon based its Athena service on it.

In 2018 Facebook wanted tighter control of the project, so Traverso, Sundstrom and Phillips left and in January 2019 started the Presto Software Foundation to continue their version, PrestoSQL. Facebook set up a rival Presto Foundation under the Linux Foundation and applied for the Presto trademark, so in December 2020 the creators renamed their fork Trino.

Why it’s built this way

Pipelined, in-memory execution instead of MapReduce: MapReduce wrote every stage’s output to disk before the next could start. Presto streams data from one stage to the next as it becomes available, which is what made ad-hoc queries interactive.
A connector API instead of its own storage: Facebook’s data lived in HDFS, HBase and custom systems such as the News Feed backend. A simple storage abstraction let one engine query all of them, and is why Trino can join an Iceberg table with PostgreSQL today.
Java, with query plans compiled to bytecode: Java was fast to develop in and fit Facebook’s Hadoop infrastructure. Generating JVM bytecode for each query plan lets the JIT compiler optimise the hot loops.
Fault tolerance added later, as an option: Skipping disk checkpoints made queries fast but meant one failed node killed the whole query. Project Tardigrade (2022) added optional retries with spooled data so long ETL jobs can survive failures.

Timeline

2012
Presto started at Facebook in the fall
2013
In production early in the year; open-sourced in November
2016
Amazon Athena launches, built on Presto
2019
Creators leave Facebook and form the Presto Software Foundation (PrestoSQL)
2020
PrestoSQL renamed Trino in December
2022
Fault-tolerant execution (Project Tardigrade); Athena engine 3 adopts Trino
2026
Release 483 ships in July

Sources11 · facts checked 5 October 2026

Improve this page on GitHub