What role does Trino play in a data lakehouse architecture?

Trino is the query engine that makes a data lakehouse architecture practical. It sits between your storage layer and your analytics consumers, translating SQL into distributed execution plans that scan object storage directly, without first loading data into a proprietary system. For data engineering teams building on open table formats, Trino provides the interactive query performance that traditional data lake approaches could never deliver. The sections below unpack the most common questions about how Trino fits into a lakehouse, where it excels, and where you need to think carefully about trade-offs. We look specifically at how the Stackable Data Platform (SDP) supports Trino deployments at the end.

How does Trino query data across a lakehouse?

Trino queries data in a lakehouse by pushing computation to the data rather than moving data to a compute engine. When you submit a SQL query, Trino’s coordinator node parses it, generates an optimized execution plan, and distributes work across worker nodes. Each worker reads data directly from object storage, S3-compatible stores or HDFS, using connectors that understand the underlying file formats and table metadata.

The key mechanism is the connector architecture. Trino does not have its own storage layer. Instead, connectors translate between Trino’s internal query model and external systems. The Hive connector, for example, reads Apache Hive™ metastore metadata to locate files, then scans Parquet or ORC files in parallel across workers. Modern table format connectors for Apache Iceberg go further, reading snapshot metadata to prune entire data files before a single row is scanned.

This design means Trino is stateless from a data perspective. Your data stays where it is, in your object store, governed by whatever access controls you apply at that layer. Trino adds the SQL interface and the distributed execution on top.

What open table formats does Trino support?

Trino supports Apache Iceberg, Apache Hive™, and Delta Lake as open table formats, with Apache Iceberg being the most fully featured integration. Each format adds metadata management on top of raw file storage, enabling features like schema evolution, time travel, and partition pruning that raw Parquet or ORC files cannot provide on their own.

Apache Iceberg is the format most actively developed alongside Trino. The Iceberg connector supports full read and write operations, including MERGE INTO, time travel queries using the AS OF syntax, hidden partitioning, and incremental reads via change data capture. For teams building a modern data lakehouse, Iceberg plus Trino is a well-tested combination.

The Hive connector remains widely used for compatibility with existing data lakes built on Hive-style partitioning. Delta Lake support exists but is generally considered less mature than the Iceberg integration. If you are starting a new lakehouse project, Apache Iceberg is the format to evaluate first.

What is the difference between Trino and a traditional data warehouse?

The core difference is where data lives and who controls it. A traditional data warehouse requires you to load data into its proprietary storage before you can query it. Trino queries data where it already lives, in open formats on storage you control. This separation of storage and compute is the defining characteristic of the data lakehouse pattern, and Trino is built around it.

Traditional warehouses bundle storage, compute, and query optimization into a single managed system. That integration delivers predictable performance and simplifies operations, but it creates dependencies. Your data is encoded in a format only that system understands, and scaling storage means scaling compute at the same time.

Trino inverts that model. You scale compute independently by adding or removing worker nodes. Your data remains in open formats that any compatible tool can read. You can run Trino alongside Apache Spark™ against the same tables without copying data. The trade-off is that you take on more operational responsibility: you manage the query engine, the metastore, and the storage layer separately rather than receiving them as a bundled service.

How does Trino handle federated queries across multiple data sources?

Trino handles federated queries by allowing a single SQL statement to reference tables from different catalogs simultaneously. Each catalog maps to a connector, and connectors can point to entirely different systems: one catalog might be an Iceberg lakehouse, another a PostgreSQL database, and a third a Kafka topic. Trino joins and aggregates across all of them at query time.

This federated query capability is one of Trino’s strongest differentiators. A query like SELECT * FROM iceberg.sales.orders JOIN postgres.crm.customers ON ... is valid Trino SQL. The coordinator generates an execution plan that pushes as much filtering as possible into each source system, then performs the join across the results in Trino’s distributed memory.

The practical implication for data platform teams is that Trino can serve as a unified query layer across a heterogeneous environment without requiring data consolidation upfront. Teams can query operational databases, streaming data, and lakehouse tables in a single statement, particularly useful during migrations or in organizations where data is spread across multiple systems by design.

What are the performance trade-offs of using Trino in a lakehouse?

Trino delivers fast interactive query performance for analytical workloads, but it is not the right tool for every job. Its in-memory processing model makes it well suited to queries that return results in seconds or minutes. It is not designed for long-running batch transformations that process terabytes over hours, and it does not persist intermediate state between queries the way a batch engine does.

Where Trino performs well

Ad hoc SQL queries against well-partitioned Iceberg tables with Parquet or ORC files are where Trino shines. Predicate pushdown, partition pruning, and dynamic filtering mean that a well-structured query touches only the files it needs. For business intelligence tools and data analysts running exploratory queries, Trino provides warehouse-like response times against open storage.

Where Trino has limitations

Trino holds intermediate query results in worker memory. Large shuffle operations, such as joining two very large unfiltered tables, can exhaust memory and cause queries to fail. Spill-to-disk is available but adds latency. For workloads that are inherently batch-oriented, Apache Spark™ is generally a better fit because it is designed around fault-tolerant, disk-spilling execution from the start. The two engines are complementary rather than competing, and many lakehouse architectures use both.

How does Trino support data governance and access control in a lakehouse?

Trino supports data governance through a layered access control model. At the system level, Trino’s built-in access control or a file-based rules engine can restrict which users or roles can access which catalogs, schemas, and tables. For more granular control, Trino integrates with Apache Ranger, which provides centralized policy management across multiple data tools in the same lakehouse.

Column-level security and row-level filtering are available through Ranger integration, meaning you can restrict access to specific columns containing sensitive data or filter rows based on the querying user’s attributes. This matters for organizations operating under data protection requirements where different teams should see different subsets of the same underlying dataset.

Trino also supports OAuth 2.0 and Kerberos for authentication, and it logs query activity that can feed into audit pipelines. One important consideration: Trino’s access controls apply at the query layer. If users have direct access to the underlying object storage, Trino’s policies do not protect that data. A complete governance model requires storage-level access controls as well, coordinated with whatever policies you define in Trino or Ranger.

How do you deploy Trino on Kubernetes for a production lakehouse?

Deploying Trino on Kubernetes for production involves running a coordinator deployment and a worker deployment, typically managed through a Kubernetes Operator. The coordinator handles query planning and client connections; workers handle distributed execution. Both need access to your metastore, your object storage credentials, and your catalog configuration files.

Key production considerations include resource limits, autoscaling, and graceful shutdown. Trino workers should have memory limits set carefully, because the query engine needs predictable memory headroom. Horizontal pod autoscaling based on CPU or custom metrics can help manage variable query loads. Graceful shutdown matters too: a worker that terminates mid-query will fail that query, so Kubernetes drain procedures should respect Trino’s shutdown grace period.

Catalog configuration, which defines your Iceberg, Hive, or other connectors, is typically mounted as Kubernetes ConfigMaps. Secrets for object storage credentials should use Kubernetes Secrets or an external secrets manager. For teams who want to see what a working deployment looks like before building their own, the SDP demo environment includes a Trino setup with Iceberg that you can inspect and run locally.

When should you use Trino instead of Apache Spark in a lakehouse?

Use Trino when your primary use case is interactive SQL queries from analysts, business intelligence tools, or dashboards. Use Apache Spark™ when you need large-scale batch processing, complex transformations, machine learning pipelines, or workloads that benefit from fault-tolerant, distributed computation with spill-to-disk support. Most production lakehouses use both.

The decision often comes down to latency requirements and query shape. Trino is optimized for low-latency responses to SQL queries that filter and aggregate data, the right choice when a user submits a query and expects an answer in seconds. Spark is optimized for throughput on large jobs where latency is less critical and the computation is complex enough to warrant a full execution framework.

A common pattern is to use Spark for data ingestion and transformation into Iceberg tables, then use Trino to serve those tables to analysts and BI tools. The two engines share the same metastore and the same table format, so there is no duplication of data. Each tool does what it does best, and the open table format is what makes the combination work without coupling.

How Stackable helps with Trino on Kubernetes

The SDP includes a dedicated Kubernetes Operator for Trino that handles the operational complexity of running Trino in production. Rather than manually managing coordinator and worker deployments, ConfigMaps, and upgrade procedures, the Operator lets you declare your desired Trino configuration in a Kubernetes custom resource and handles the rest.

Automated lifecycle management: The Trino Operator manages rolling upgrades, restarts, and configuration changes without manual intervention.
Integrated catalog configuration: Catalog definitions for Iceberg, Hive, and other connectors are managed as part of the custom resource, with secrets handled through Kubernetes-native mechanisms.
Composable platform: Trino runs alongside other SDP-managed components, including Apache Kafka® for streaming and Apache Spark™ for batch, all on the same Kubernetes cluster with shared authentication and monitoring.
Open source and cloud-agnostic: The SDP and its Trino Operator are fully open source. You run them on your own infrastructure, on any cloud, or on-premises, with no dependency on a specific cloud provider.
Data sovereignty by design: Your data stays in your storage layer. The SDP adds the query and orchestration layer on top without requiring data to leave your environment.

If you want to see how this works in practice before committing to a deployment, the SDP demos include a working Trino and Iceberg setup you can run yourself. To talk through your specific architecture or requirements, get in touch with the Stackable team.

Apache Kafka® is a registered trademark of The Apache Software Foundation. Apache Hive™, Apache Spark™, Apache Iceberg, and Apache ZooKeeper™ are trademarks of The Apache Software Foundation. Use of these marks does not imply endorsement by The Apache Software Foundation. Trino is a trademark of the Trino Software Foundation.