Trino and Apache Iceberg work together as a query engine and open table format pair. Trino runs the SQL queries, and Iceberg provides the structured, versioned table layer sitting on top of object storage. Together, they give you a fully open, SQL-accessible data lakehouse with no proprietary lock-in. What follows walks through each layer of this integration, from catalog configuration to time travel queries and performance tuning.
We cover how the Stackable Data Platform (SDP) supports this stack at the end.
What does Apache Iceberg actually add to a data lake?
Apache Iceberg adds a structured table format on top of raw object storage. It turns a collection of files into a queryable, transactional table with a defined schema, partition layout, and full version history. Without something like Iceberg, a data lake is essentially a folder of files, with no schema enforcement, no atomic writes, no way to query historical states.
Concretely, Iceberg brings four things that a plain data lake lacks:
- ACID transactions: Writes are atomic. A failed job does not leave partially written data visible to readers.
- Schema evolution: You can add, rename, or reorder columns without rewriting existing data files.
- Partition evolution: Partition strategies can change over time without breaking existing queries or requiring data migration.
- Snapshot-based versioning: Every write produces a new snapshot. This is the foundation for time travel and audit capabilities.
Iceberg achieves this through a layered metadata structure. A catalog tracks the current metadata pointer, a metadata file describes the table schema and snapshots, manifest lists enumerate data file locations, and the actual data sits in Parquet, ORC, or Avro files. Separating metadata from data is what makes Iceberg engine-agnostic and composable with multiple query engines at the same time.
How does Trino read and write Iceberg tables?
Trino reads and writes Iceberg tables through its native Iceberg connector, which handles both metadata resolution and data file I/O. When you run a query, Trino contacts the Iceberg catalog to resolve the current snapshot, reads the relevant manifest files to identify which data files to scan, applies partition and column pruning, and then reads only the necessary data directly from object storage.
For writes, Trino supports INSERT, INSERT OVERWRITE, MERGE, UPDATE, and DELETE on Iceberg tables. Each write operation produces a new snapshot atomically, so concurrent readers always see a consistent state of the table, even while a write is in progress.
The Iceberg connector also supports several configuration options at the table and session level: the target file size for new data files, the default file format (Parquet is the most common choice), and compression codecs. These settings directly affect both query performance and storage efficiency, so they are worth reviewing before moving workloads to production.
What is the role of the Iceberg catalog in a Trino lakehouse?
The Iceberg catalog is the central registry that maps table names to their current metadata location. Without it, neither Trino nor any other engine would know where a table’s metadata file lives, making the table effectively invisible. In a Trino lakehouse, the catalog is what makes tables discoverable and shareable across engines.
Trino supports several catalog implementations for Iceberg:
- Hive Metastore (HMS): The most widely deployed option. Apache Hive™ Metastore stores table locations and metadata pointers in a relational database, and Trino reads from it using the standard Thrift protocol.
- AWS Glue: A managed alternative to HMS for teams running on AWS. It behaves similarly from Trino’s perspective but is operated by the cloud provider.
- REST catalog: The newer, engine-agnostic standard defined by the Iceberg community. It exposes a REST API that any compatible engine can call, making it the most interoperable option.
- JDBC catalog: Stores metadata directly in a relational database, useful for simpler setups.
- Nessie: A Git-like catalog that adds branching and tagging semantics on top of standard Iceberg catalog behavior.
Catalog choice matters most in multi-engine setups. If both Trino and Apache Spark™ need to access the same tables, they must share a catalog. The REST catalog and Hive Metastore are the most common choices for this scenario.
How does time travel work when querying Iceberg tables with Trino?
Time travel works by querying a specific historical snapshot of a table rather than its current state. Every write to an Iceberg table creates a new snapshot with a unique snapshot ID and a timestamp. Trino can target any of these snapshots directly in SQL, without copying data or maintaining separate historical tables.
Trino supports two time travel syntaxes for Iceberg tables:
- By snapshot ID:
SELECT * FROM table FOR VERSION AS OF 1234567890 - By timestamp:
SELECT * FROM table FOR TIMESTAMP AS OF TIMESTAMP '2025-01-15 10:00:00'
This is useful for auditing, debugging pipelines, and reproducing historical results. If a transformation job produced incorrect output, you can query the source table as it existed before the job ran, compare the two states, and identify exactly what changed.
One practical consideration: Iceberg’s snapshot expiry settings control how long old snapshots are retained. If snapshots are expired aggressively, time travel queries targeting those snapshots will fail. Retention policies should be set with your audit and debugging requirements in mind, not just storage costs.
Can Trino and Spark read the same Iceberg tables simultaneously?
Yes. Trino and Apache Spark™ can read and write the same Iceberg tables at the same time, provided they share a common catalog. This is one of Iceberg’s core design goals: engine interoperability through a shared, open table format. Both engines see the same snapshot history, the same schema, and the same data files.
Concurrent reads from multiple engines are always safe. Concurrent writes are coordinated through optimistic concurrency control at the catalog level. If two engines attempt conflicting writes simultaneously, Iceberg’s commit protocol detects the conflict and one write will be retried or fail, depending on the operation type. For most analytical workloads, where Spark handles heavy batch transformations and Trino handles interactive queries, write conflicts are rare in practice.
This multi-engine capability is what makes the open lakehouse approach genuinely practical. You are not forced to route all workloads through a single engine. Batch ingestion, streaming, and interactive analytics can each use the engine best suited to the task, all operating on the same underlying tables.
What are the performance considerations when running Trino on Iceberg?
Performance depends on four main factors: file sizing, partition design, metadata volume, and statistics availability. Getting these right has a larger impact on query speed than almost any configuration tuning.
File sizing and compaction
Iceberg tables that receive many small writes accumulate many small files over time. Trino performs best when data files are in the range of 128 MB to 512 MB. Too many small files means more metadata to read and more I/O operations per query. Regular compaction, using Trino’s ALTER TABLE ... EXECUTE optimize procedure or a Spark job, keeps file sizes healthy.
Partition design and pruning
Iceberg’s hidden partitioning means query predicates can be automatically matched to partitions without requiring users to include partition columns explicitly in their WHERE clauses. For this to work efficiently, your partition spec must align with your most common query patterns. Partitioning by date is the most common choice for event-style data. Over-partitioning, such as partitioning by a high-cardinality column, produces the same small-file problem as frequent small writes.
Statistics and column pruning
Iceberg tracks column-level statistics (min, max, null counts) in manifest files. Trino uses these for predicate pushdown, skipping data files that cannot contain matching rows. Keeping statistics fresh after large updates or deletes improves query selectivity significantly. Parquet’s columnar format also allows Trino to read only the columns referenced in a query, reducing I/O further.
When should a team choose Trino with Iceberg over a managed data warehouse?
The Trino and Iceberg combination makes sense when you need full control over your data, want to avoid being tied to a single vendor’s pricing or product roadmap, or need to run workloads across multiple environments, including on-premises infrastructure. Managed data warehouses offer convenience, but that convenience comes with real constraints: where data lives, which engines can access it, and what the long-term cost structure looks like.
This combination is a strong fit when:
- Data sovereignty requirements mean data cannot leave a specific jurisdiction or infrastructure boundary.
- Multiple engines (Spark, Trino, Flink) need to share the same tables without data duplication.
- The team wants to decouple compute costs from storage costs and scale each independently.
- Workloads are large enough that managed warehouse pricing becomes a significant line item.
- Interoperability with other open-source tools is a priority.
The trade-off is operational responsibility. Running Trino and Iceberg yourself means managing the query engine, the catalog, the object storage layer, and compaction jobs. Teams without dedicated platform engineering capacity may find the overhead significant, at least initially. That gap is where a well-structured deployment platform helps, and it is worth looking at working demos to understand what a production-ready setup actually looks like.
For teams with the engineering capacity, the long-term flexibility of an open, composable stack typically outweighs the upfront investment.
How Stackable helps with Trino and Apache Iceberg
The Stackable Data Platform (SDP) provides a Kubernetes-native way to deploy and operate Trino as part of a complete open lakehouse stack. Rather than assembling each component manually, SDP lets you declare your desired setup in configuration and handles provisioning, configuration, and lifecycle management from there.
Specifically, SDP helps teams working with Trino and Iceberg by:
- Deploying the Stackable Operator for Trino alongside a Hive Metastore or compatible REST catalog, so the catalog layer is configured and connected from the start.
- Integrating Apache Spark™ into the same platform, enabling the multi-engine pattern where Spark handles batch ingestion and Trino handles interactive SQL, both reading the same Iceberg tables.
- Running entirely on your own infrastructure, whether on-premises, in any cloud, or in a hybrid setup, so data sovereignty requirements are met without compromise.
- Providing infrastructure-as-code configuration for the full stack, making deployments reproducible and auditable.
If you want to see what a working Trino and Iceberg deployment looks like on Kubernetes, the SDP demo environment is a good starting point. For questions about your specific setup or requirements, get in touch with the Stackable team directly.