Trino

Overview

Trino is a distributed SQL query engine built for one job above all others: querying data where it already lives, across many systems, in a single statement. It owns no storage and no table format.

A cluster is one coordinator and zero or more workers. The coordinator parses statements, plans queries and manages the workers; the workers fetch data from connectors and exchange intermediate results with each other.

A query becomes a hierarchy of stages, translated into tasks on workers, each task running drivers over splits, which are sections of a larger dataset. Execution is pipelined and in memory rather than staged to disk.

Connectors are the whole story. The project's own analogy is that a connector is like a database driver, and each one is exposed as a catalogue you configure in a properties file.

The connector list is the broadest here, 44 in the current release, spanning Delta Lake, Iceberg, Hudi and Hive, the big three warehouses, a dozen relational databases, and Kafka, Elasticsearch, MongoDB and Cassandra.

Be clear about what it is not. The documentation states plainly that Trino is not a general-purpose relational database, is not a replacement for MySQL, PostgreSQL or Oracle, and was not designed for transactional workloads.

Resilience improved with fault-tolerant execution, which retries failed queries or individual tasks. Task-level retries need an exchange manager spooling intermediate data to object storage, so budget for that.

Governance of the project itself is worth knowing when comparing it with Starburst. Trino belongs to the Trino Software Foundation, an independent non-profit registered in Delaware, not to any vendor.

Community scale as published: 13,000 Slack members, 10,000 GitHub stars and more than 775 contributors, with regular community broadcasts and contributor calls.

Key features and capabilities

The same headings are used for every query & processing engines entry, so two tools can be read side by side.

Execution model

• One coordinator plans and schedules; workers execute and exchange intermediate data
• Queries become stages, then tasks, then drivers running over splits of the source data
• Pipelined in-memory execution through operators that consume, transform and produce data
• Eager execution of submitted SQL, with no lazy DataFrame API

Languages and APIs

• SQL is the only interface, and the engine is ANSI SQL compliant
• A command-line client and a JDBC driver ship with the project
• Project-maintained clients for Go, JavaScript, Python and C#
• No DataFrame or notebook API of its own

Data sources and formats

• 44 connectors in the current release, configured as catalogues in properties files
• Table formats, Delta Lake, Iceberg, Hudi and Hive, on S3, Azure and Google Cloud storage
• Warehouses and databases, including BigQuery, Snowflake, Redshift, PostgreSQL, MySQL, SQL Server and Oracle
• Also Kafka, Elasticsearch, OpenSearch, MongoDB, Cassandra, ClickHouse, Druid, Pinot, Prometheus and Redis

Performance and scale

• Parallelism across workers by splits, with driver-level parallelism inside each task
• Fault-tolerant execution retries whole queries or individual tasks
• Task retries require an exchange manager spooling to S3, Azure, Google Cloud Storage or HDFS
• The project publishes no benchmark results of its own, though TPC-H and TPC-DS data generators ship with it

What it suits

• Suits federation, analysis, aggregation over large datasets and reporting
• Positioned as an alternative to querying HDFS through MapReduce pipelines such as Hive or Pig
• Explicitly not for transactional workloads, and not a replacement for a general-purpose database
• Claimed to query exabyte-scale lakes and large warehouses at the biggest organisations

Ecosystem

• A plugin architecture covering connectors and other plugin types
• Read and write support for all three open table formats in this category
• Regular community broadcasts, monthly contributor calls and subproject syncs
• Published community scale, 13,000 Slack members and more than 775 contributors

Where it runs and what it costs

• Self-hosted clusters, Docker containers, or Kubernetes through the official Helm chart
• Managed commercially as Starburst Galaxy; self-managed commercially as Starburst Enterprise
• No hosted service from the foundation itself
• No formal release cadence; gaps between recent releases have run from six weeks to three months

Pricing

Open sourceFree, Apache 2.0

Trino is free under Apache 2.0 and the foundation sells nothing. Commercial cost, if you want a managed service or support, comes from Starburst, whose published Galaxy tiers start at a free tier of up to three clusters, then Pro from $0.50 a credit, Enterprise from $0.75 and Mission-Critical from $1.00, a credit being a universal unit of compute. A 30-day trial includes $500 of Galaxy compute before dropping to the free tier. Starburst Enterprise, the self-managed distribution, is quote-only.

Vendor pricing page →

Demos and videos

• Trino channel Channel or playlist · YouTube
• What is Trino? Tutorial · YouTube

About Trino Software Foundation

The engine began as Presto, created in 2012 by Dain Sundstrom, David Phillips and Martin Traverso on Facebook's data infrastructure team, and was renamed Trino in December 2020. It is now owned by the Trino Software Foundation, an independent non-profit corporation registered in Delaware, whose board is those same three creators, and which handles accounting, legal matters, trademarks, repositories and contributor agreements. All foundation projects are Apache 2.0. Starburst sells the main commercial distributions and employs Traverso as its chief technology officer, but the project is not company-owned.

Founded 2020 · Delaware, United States · trino.io