Trino: distributed SQL query engine for big data

What Trino is

Trino is a fast distributed SQL query engine for big data analytics. It lets analysts, engineers and applications run SQL against data where it already lives, whether that is object storage holding Hive, Iceberg, Delta Lake or Hudi tables, relational databases such as PostgreSQL, MySQL, Oracle and SQL Server, or systems like Kafka, Elasticsearch, OpenSearch, Cassandra, ClickHouse, MongoDB and Prometheus. A single query can join data from several of those sources, because each one is exposed to Trino as a catalog.

The repository describes Trino as formerly known as PrestoSQL, and the documentation points readers to the research paper Presto: SQL on Everything and the book Trino: The Definitive Guide for background on its concepts. The project is written in Java, licensed under Apache-2.0 and developed on GitHub under the trinodb organisation.

The documentation is careful to say what Trino is not. Although many people call it a database, Trino is not a general-purpose relational database and is not a replacement for MySQL, PostgreSQL or Oracle. It was not designed for online transaction processing. It was designed for data warehousing and analytics: querying very large amounts of data with distributed queries, aggregating it and producing reports, the workloads usually called OLAP. Historically it was built as an alternative to tools such as Hive and Pig that query HDFS through pipelines of MapReduce jobs, but it is not limited to HDFS.

How it works

Coordinator and workers

A Trino cluster consists of one coordinator and zero or more workers, each running Trino in a single JVM. Users connect to the coordinator with a SQL client. The coordinator parses statements, plans queries, manages worker nodes and tracks the activity of each worker; the documentation calls it the "brain" of an installation. Workers execute tasks and process data: they fetch data from connectors and exchange intermediate data with each other, and the coordinator gathers results from the workers and returns them to the client. When a worker starts, it advertises itself to the discovery server in the coordinator. Coordinators, workers and clients communicate over REST APIs. For development or testing, a single instance can act as both coordinator and worker.

Connectors, catalogs, schemas and tables

A connector adapts Trino to a data source, much like a database driver. Connectors implement Trino's service provider interface (SPI), and Trino ships many of them: data lake and lakehouse connectors (Delta Lake, Hive, Hudi, Iceberg and a Lakehouse connector), relational connectors (MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, Redshift, SingleStore, Snowflake and others), connectors for systems such as BigQuery, Cassandra, ClickHouse, Druid, DuckDB, Elasticsearch, Kafka, Loki, MongoDB, OpenSearch, Pinot, Prometheus and Redis, and utility connectors such as JMX, System, Memory, Black Hole, Faker, TPC-H and TPC-DS.

A catalog is a set of configuration properties for one data source, including the connector name and details such as credentials and URLs. Catalogs live in properties files in the configuration directory, and the file name sets the catalog name, so etc/example.properties becomes the catalog example. You can configure many catalogs, including several that use the same connector, for example two Hive catalogs for two data lakes, and query across them in one statement. Catalogs contain schemas, schemas contain tables and views, and fully qualified names are always rooted in a catalog, as in example.test_data.test.

Query execution

Trino executes ANSI-compatible SQL. When it parses a statement it creates a query and a distributed query plan, which is realised as a tree of stages with a root stage that aggregates the output of the others. Stages are the coordinator's model of the plan; they are executed as tasks distributed over workers. Tasks operate on splits, sections of a larger data set that the coordinator obtains from a connector when scheduling a query. Each task runs one or more parallel drivers, sequences of operators such as table scans and filters, and exchanges move data between nodes for different stages. Understanding this vocabulary helps when reading query plans and the web UI, and the documentation recommends it to end users who want to write efficient queries, not only to administrators.

Plugins

Trino uses a plugin architecture to integrate with data sources and other systems. The default server tarball and Docker image include all plugins; the minimal server-core tarball and trinodb/trino-core image contain only essential plugins and are intended as bases for custom builds, and the trino-packages project can assemble a tarball or image with a chosen set of plugins.

Key features

• Federated SQL: query and join data across many systems through catalogs, without first copying it into a single warehouse.
• Lakehouse table formats: dedicated connectors for Iceberg, Delta Lake, Hudi and Hive tables on object storage and HDFS.
• Distributed, parallel execution: work is spread across all workers and further parallelised with threads inside each JVM.
• Fault-tolerant execution: optional retry policies (QUERY or TASK) spool intermediate exchange data so failed queries or tasks can be retried instead of failing outright.
• Dynamic catalog management: with CATALOG_MANAGEMENT set to dynamic, catalogs can be created and dropped with SQL statements instead of editing files.
• Broad client support: a terminal CLI, a web UI, a JDBC driver, and Python, Go and other clients listed on trino.io.
• Pluggable security: TLS, shared-secret internal communication, authentication via password file, LDAP, OAuth 2.0, certificates, JWT, Kerberos or Salesforce, and access control via file-based rules, Open Policy Agent or Apache Ranger.
• Extensibility: the SPI supports custom connectors and custom access control implementations.
• Reproducible builds: the README states Trino supports reproducible builds as of version 449.

Getting started

The quickest way to try Trino is the official Docker image, which includes the server, all plugins, a default configuration and some sample catalogs. Run it in the background with the default port mapped:

docker run --name trino -d -p 8080:8080 trinodb/trino

Without a tag, the image defaults to latest; any released version number can be used instead. docker ps shows (health: starting) while the server boots and (healthy) once it is ready. The image includes the CLI, so you can open a SQL session inside the container and query the bundled TPC-H sample data:

docker exec -it trino trino
select count(*) from tpch.sf1.nation;

To use your own configuration, mount an etc directory at /etc/trino; to keep the defaults and only add catalogs, mount catalog files at /etc/trino/catalog. Additional plugins go in /usr/lib/trino/plugin. To manage catalogs with SQL instead of files, start the container with dynamic catalog management:

docker run --name trino -d -p 8080:8080 -e CATALOG_MANAGEMENT=dynamic trinodb/trino

Catalogs created this way only survive restarts if a volume is mounted at /etc/trino/catalog. The standalone CLI is a self-executing JAR: download it, rename it to trino, make it executable and point it at a coordinator:

./trino --version
./trino http://trino.example.com:8080

The CLI needs Java 11 or later (Java 22 or later is recommended for faster decompression), and its version should match the cluster or be newer; versions before 350 are not supported. For Kubernetes, the documentation's fastest route is the official Helm chart:

helm repo add trino https://trinodb.github.io/charts
helm install example-trino-cluster trino/trino

Default chart values can be overridden with a YAML file passed through -f. To build from source, the README lists Mac OS X or Linux, Java 25.0.1 or later and Docker as requirements, and the standard Maven build skips tests:

./mvnw clean install -DskipTests

Deploying on servers

For a tarball deployment, the documentation requires 64-bit Linux and a 64-bit Java 25 runtime with a minimum of 25.0.1. Earlier releases such as Java 17, 21 or 24 do not work, and newer versions such as Java 26 are untested. The project recommends Eclipse Temurin, the JDK it tests against and ships in its Docker image. It also recommends raising nofile and nproc ulimits for the Trino user, giving starting values of 131072 and 128000.

Configuration lives in an etc directory: node.properties (environment name, a unique node ID and the data directory), jvm.config (JVM options, one per line), config.properties (server settings, including whether the node is a coordinator and the discovery URI) and catalog properties files. The documentation suggests setting -Xmx to roughly 70 to 85 percent of the machine's memory, recommends more than 32GB for production clusters, and advises disabling swap. The JVM's temporary directory must not be mounted noexec, because Trino loads shared libraries from it; otherwise Trino can fail to start. Larger clusters perform best with a dedicated coordinator that does not also schedule work on itself.

Security model in practice

All client access to a Trino cluster goes through the coordinator, so securing a cluster largely means securing the coordinator: encrypting client traffic with HTTPS and TLS (ideally terminated at a load balancer or proxy with a globally trusted certificate), identifying users, and checking their access rights. User mapping rules can translate complex identities such as [email protected] into simple Trino usernames, and group mapping assigns users to groups to simplify rules. File-based access control lets you restrict access at the catalog, schema or table level, and Apache Ranger adds row filters, column masking and audit logs at query time. By default, a SELECT * that touches columns a user cannot see fails with an access error; setting hide-inaccessible-columns silently hides them instead. Inside the cluster, internal communication between coordinator and workers can be secured with a shared secret, and secrets in catalog files can be handled with secrets management. Access from Trino to each data source is configured per catalog, using whatever security options that connector supports.

Use cases

• Interactive analytics on a data lake: analysts query Iceberg or Hive tables on object storage with standard SQL and BI tools via JDBC, without loading data into a separate warehouse.
• Federated queries: join operational data in PostgreSQL or MySQL with historical data in the lake, or combine several databases, in a single statement.
• Replacing MapReduce-era batch jobs: the documentation positions Trino as an alternative to Hive and Pig pipelines for reporting and aggregation.
• Large batch ETL with retries: with a TASK retry policy and an exchange manager, long-running batch queries can survive individual worker failures.
• A shared SQL access layer: one Trino cluster with centralised authentication and Ranger or OPA policies gives many teams governed access to many data sources.

How it compares

Trino belongs to the distributed SQL query engine category. Its documentation compares it directly only to two groups: transactional databases such as MySQL, PostgreSQL and Oracle, which it does not aim to replace, and MapReduce-based tools such as Hive and Pig, which it was built as an alternative to. Other engines in the same space include Presto (the project Trino grew out of, as the repository's "formerly known as PrestoSQL" note indicates) and Apache Spark SQL; teams usually compare them on query latency for interactive workloads, connector coverage and operational model rather than on SQL features alone.

Compared with a cloud data warehouse, Trino separates compute from storage: it stores no data of its own and queries data in place through connectors. That brings flexibility and avoids loading pipelines, but performance and features depend on the connector and the underlying storage, and you operate the cluster yourself unless you use a hosted distribution.

Things to know before adopting

• No security by default. The security overview states that a default installation has no security features enabled, and the default access control allows all operations for all authenticated users. The recommended order is TLS, then a shared secret for internal communication, then authentication (start with a password file), then authorization rules, one step at a time with a restart and verification after each.
• Queries fail on node failure unless you opt in. Fault-tolerant execution is off by default. Turning it on with retry-policy=QUERY or TASK can make queries fail on connectors that do not support retries, and TASK requires an exchange manager. The docs suggest a separate cluster for TASK-retry batch work, because it can add latency to high volumes of short queries.
• Strict Java requirements. The server needs exactly the Java 25 line (25.0.1 or later); building from source also needs Docker, and on Apple Silicon Rosetta 2 for some web UI build dependencies.
• Memory planning. Trino is memory-hungry by design; the deployment guide's sizing advice (large heaps, no swap, heap dumps on out-of-memory errors) assumes dedicated machines.
• Connector behaviour varies. Type mapping, supported SQL statements and fault-tolerance support differ by connector and are documented per connector.
• Not for OLTP. Trino is the wrong tool for high-rate single-row reads and writes; keep those in an operational database and query them through a connector.
• Frequent numbered releases. Trino uses plain incrementing version numbers; keep CLI and server versions aligned, as the CLI docs only regularly test matching or newer clients.

Project activity

As of November 2026 the trinodb/trino repository has about 13,400 stars on GitHub. It was created in January 2019, is written in Java and is licensed under Apache-2.0. The most recent release at the time of writing is version 484, published in mid-October 2026, and the repository received commits on the day of writing. Development guidelines, contribution requirements and the security policy are linked from the README, and the community gathers on the Trino Slack.

The source is at github.com/trinodb/trino. Documentation, downloads and the ecosystem directory of data sources and clients are on trino.io, with the user manual at trino.io/docs/current.

[![Featured on TechLogHub](https://techloghub.com/badge-neutral.svg)](https://techloghub.com/open-source/trino?utm_source=techloghub_badge&utm_medium=referral&utm_campaign=readme)