Lakehouse Query Engines: Trino vs StarRocks vs DuckDB

A modern data lakehouse separates the data it stores from the software that computes over it. Table formats such as Apache Iceberg or Delta Lake define how records, partitions, and transactions are laid out as files on object storage, but they do not execute queries. That work belongs to a distinct tier: the query engine. Because storage and compute are decoupled in a lakehouse, an organization can place several different engines over the same files and choose among them per workload. This guide examines three query engines that occupy very different points in that design space — Trino, StarRocks, and DuckDB — and explains how their architectures, deployment models, pushdown behavior, and caching strategies determine which one fits a given use case. The comparison is deliberately confined to the compute tier; the underlying file and table formats are treated as a fixed substrate rather than re-derived here.

The engines were chosen because they represent three archetypes rather than three interchangeable products. Trino is a distributed, federated massively parallel processing (MPP) engine built for ad-hoc SQL across many sources. StarRocks is an MPP online analytical processing (OLAP) engine designed for interactive, high-concurrency serving on the lakehouse. DuckDB is a single-node, in-process engine that queries lakehouse tables directly from inside a host program without any cluster. Understanding why each exists, and where each stops being the right tool, is more durable than memorizing a feature list, because the storage-compute separation that makes the lakehouse attractive also makes engine selection a recurring decision rather than a one-time commitment.

The Query-Engine Tier of the Lakehouse

A lakehouse is a data architecture that places a transactional table layer over inexpensive object storage so that a single copy of the data serves both exploratory analytics and production reporting. Its defining property is the separation of storage from compute. Data files, most often Apache Parquet, sit in an object store such as Amazon S3. A table format layered on top of those files records which files belong to a table, how they are partitioned, and which version of the table is current. Query engines then read that table format and execute SQL. Because no engine owns the data, several can read the same tables concurrently, and an organization can add or replace an engine without migrating a single byte.

This decoupling is what distinguishes a lakehouse from a classical data warehouse, in which storage and compute are fused inside one proprietary system. The trade-off is that reading data now crosses a network boundary to object storage, which has higher and more variable latency than a local disk. Much of what differentiates the engines in this comparison is how they cope with that boundary: how aggressively they avoid reading files at all, and how they cache the files they must read. The table format itself is out of scope here; readers who need the storage-substrate details can consult the companion analysis of Iceberg, Delta Lake, and Hudi table formats, and the treatment of the file layer in the guide to Parquet and Apache Arrow columnar storage.

Two mechanisms recur throughout the comparison and are worth defining once. Predicate pushdown is the practice of pushing a query’s filter conditions down to the storage layer so that files, partitions, or row groups that cannot match are never read. Projection pushdown reads only the columns a query references, which is efficient because Parquet stores data column by column. Both reduce the volume of bytes crossing the network boundary, and the degree to which an engine exploits them is a primary determinant of its latency over object storage.

Trino: Federated Distributed MPP

Trino is a distributed SQL query engine designed for interactive and ad-hoc analytics across large and heterogeneous datasets. It follows the massively parallel processing model, meaning a query is divided into parallel units of work that execute simultaneously across many machines. Trino uses date-independent sequential release numbers and ships frequently; the latest release at the time of writing is Trino 482, published on 2026-06-25 (github.com/trinodb/trino/releases; trino.io, as of 2026-07-11). Its defining characteristic is federation: a single Trino cluster can query many different data sources in one statement, joining a lakehouse table against a relational database without moving either.

Coordinator and Workers

A Trino cluster consists of one coordinator and zero or more workers. The coordinator is the brain: it receives SQL statements from clients, parses and analyzes them, builds a distributed execution plan, and schedules and monitors the work assigned to the workers. Workers execute the tasks they are given and process the underlying data. Each node runs as a single Java Virtual Machine (JVM) process and achieves parallelism through many threads within that process. A cluster with more workers can process more data concurrently, which is how Trino scales: an operator adds worker nodes to raise throughput rather than replacing the cluster with a larger one (trino.io/docs/current/overview/concepts.html, as of 2026-07-11).

The internal decomposition of a query is precise and worth following, because it explains both Trino’s parallelism and its memory behavior. A client submits a statement, the text of the SQL. Trino turns it into a query, the running instance of that statement. The query plan is a tree of stages, each of which is realized as a set of tasks distributed across workers. Each task processes splits, which are addressable sections of the input data, using a pipeline of drivers and operators that apply the actual relational logic. Data moves between stages through exchanges. This structure is the classic distributed, federated MPP execution model, and it allows a single large scan to be spread across every worker in the cluster.

Connectors and Catalogs

Trino’s federation rests on two concepts. A connector adapts Trino to a particular kind of data source; connectors exist for Hive, Delta Lake, Iceberg, PostgreSQL, and many other systems. A catalog is a configured instance of a connector pointing at a specific data source. Multiple catalogs coexist in one cluster, and because a query can reference tables from more than one catalog, Trino can join across sources in a single statement. The namespace is three levels deep: catalog, then schema, then table (trino.io/docs/current/overview/concepts.html, as of 2026-07-11). A catalog is defined by a small properties file. The following configures an Iceberg catalog backed by a REST catalog service and S3 storage.

# etc/catalog/lakehouse.properties
connector.name=iceberg
iceberg.catalog.type=rest
iceberg.rest-catalog.uri=https://catalog.example.com/api/catalog
fs.native-s3.enabled=true
s3.region=us-east-1
# turn on the local file-system cache for this catalog
fs.cache.enabled=true
fs.cache.directories=/mnt/trino-cache

With this catalog registered, a query such as SELECT * FROM lakehouse.sales.orders o JOIN postgres.crm.customers c ON o.cust_id = c.id reads the orders table from Iceberg on S3 and joins it against a live PostgreSQL table, with the join executed in the Trino cluster. This is the federation capability that makes Trino a shared query gateway over a mixture of lakehouse tables and operational databases. It also positions Trino as a convenient execution engine beneath a transformation framework; a project that models tables with the dbt transformation tool can compile its SQL against a Trino target and reach every registered catalog through one connection.

Pushdown and Caching in Trino

For lakehouse tables, Trino’s Iceberg connector applies predicate pushdown to drive partition and file pruning, so that a filtered query skips partitions and data files that cannot satisfy the condition, and projection pushdown to read only the referenced columns. Vectorized readers handle both Parquet and ORC file formats (Trino Iceberg connector documentation, trino.io, as of 2026-07-11). Pushdown reduces work but does not remove the cost of repeatedly fetching the same files from object storage. To address that, Trino provides a file-system cache for the Delta Lake, Hive, and Iceberg connectors, with Hudi support noted as forthcoming, and native support for Alluxio as a distributed caching layer in front of object storage, enabled with fs.alluxio.enabled=true. The older Rubix caching path has been superseded by the native file-system cache (trino.io/docs/current/object-storage/file-system-cache.html and file-system-alluxio.html, as of 2026-07-11).

StarRocks: MPP OLAP Serving on the Lakehouse

StarRocks is an MPP OLAP engine oriented toward interactive analytics: sub-second dashboards, high-concurrency BI, and repeated queries over lakehouse tables. It is a Linux Foundation project (github.com/StarRocks/starrocks, as of 2026-07-11). The latest major release is StarRocks 4.0, released on 2025-10-17. The vendor reports roughly 60 percent faster query execution year over year on the TPC-DS benchmark for 4.0; this is a self-reported figure and should be read alongside the benchmark caveat below (starrocks.io/blog/starrocks-2025-year-in-review, as of 2026-07-11). Where Trino optimizes for breadth of sources, StarRocks optimizes for the speed and concurrency of repeated queries over a smaller set of well-modeled tables.

Frontend, Backend, and Compute Nodes

StarRocks also follows the MPP model but uses two primary node types. The Frontend (FE) manages metadata, handles client connections, parses SQL, and performs query planning and scheduling. The Backend (BE) stores data and executes the query fragments assigned to it against its local storage. A third node type, the Compute Node (CN), is effectively a Backend without attached storage, used to separate compute from storage (docs.starrocks.io/docs/introduction/Architecture/, as of 2026-07-11). The division of labor resembles Trino’s coordinator-and-worker split, but StarRocks integrates a storage role into its Backend nodes, which is central to its two deployment modes.

In shared-nothing mode, Backends hold table data on their own local storage, which yields the lowest read latency but couples storage capacity to compute capacity. In shared-data mode, the Frontend coordinates a fleet of stateless Compute Nodes while the authoritative data lives on object storage or HDFS, with a local cache smoothing access. Shared-data mode is StarRocks’ answer to storage-compute separation: it retains the elasticity of a lakehouse, in which compute can scale independently, while keeping a warm local cache so that repeated queries do not pay full object-storage latency each time (docs.starrocks.io/docs/introduction/Architecture/, as of 2026-07-11).

Optimizer, Materialized Views, and Data Cache

StarRocks pairs a fully vectorized execution engine and columnar storage with a cost-based optimizer (CBO), which estimates the cost of alternative execution plans and chooses the cheapest rather than following the query’s written order (starrocks.io/blog/introduction_to_starrocks, as of 2026-07-11). On top of this sits the feature most responsible for its interactive performance on the lakehouse: materialized views (MVs). A materialized view is a precomputed, stored result of a query that the engine can substitute for the original computation. StarRocks supports multi-column partitioned MVs that align with Iceberg or Hive partitions, which allows incremental refresh — only the changed partitions are recomputed rather than the whole view. The cost-based optimizer performs transparent query rewriting, redirecting an incoming query to an eligible MV without the author referencing it. The vendor reports MV-driven speedups of up to 10 to 100 times on eligible queries; this is a self-reported figure (starrocks.io/blog/starrocks-2025-year-in-review; docs.starrocks.io async_mv documentation, as of 2026-07-11).

An external catalog connects StarRocks to a lakehouse without ingesting the data, and a materialized view built on that catalog becomes the acceleration layer. The following sketch registers an Iceberg catalog and defines an MV that the optimizer can transparently rewrite queries onto.

-- Register the lakehouse as an external catalog
CREATE EXTERNAL CATALOG iceberg_cat
PROPERTIES (
  "type" = "iceberg",
  "iceberg.catalog.type" = "rest",
  "iceberg.catalog.uri" = "https://catalog.example.com/api/catalog"
);

-- Precompute a daily rollup, partition-aligned for incremental refresh
CREATE MATERIALIZED VIEW sales_daily
PARTITION BY order_date
REFRESH ASYNC
AS
SELECT order_date, region, sum(amount) AS revenue
FROM iceberg_cat.sales.orders
GROUP BY order_date, region;
-- Queries that match this pattern are rewritten onto the MV by the CBO

Beneath the MV layer, StarRocks provides a Data Cache that caches blocks of remote files locally to smooth the latency and jitter of object storage. StarRocks 4.0 added metadata caching, compaction, and file bundling that the vendor reports reduce cloud API calls by up to 90 percent, and strengthened Iceberg support with hidden-partition handling, faster metadata parsing, a new compaction API, and native Iceberg table writes; 4.0 also introduced JSON as a first-class type, reported at 3 to 15 times faster on JSON queries. These are self-reported figures (starrocks.io/blog/starrocks-2025-year-in-review, as of 2026-07-11).

DuckDB and DuckLake: In-Process Lakehouse Analytics

DuckDB occupies the opposite end of the spectrum from Trino and StarRocks. It is a single-node, in-process, vectorized analytical engine — often described as SQLite for analytics — that runs inside the host process rather than as a separate cluster. There is no coordinator, no worker fleet, and no network protocol between the application and the engine; a query executes in the same process as the program that issued it. The current stable line is DuckDB 1.5.x, with v1.5.3 shipping on 2026-05-29 (duckdb.org, as of 2026-07-11). This design removes distributed-systems overhead entirely, at the cost of being bounded by one machine’s memory and cores, with no distributed shuffle. DuckDB’s role as a general in-process SQL and dataframe engine is examined in the companion comparison of DuckDB and Polars for in-process analytics; the concern here is narrower — its role as a lakehouse engine.

Lakehouse Formats as First-Class Citizens

DuckDB reads and writes lakehouse tables through native extensions rather than third-party libraries. The iceberg extension handles Apache Iceberg, the delta extension handles Delta Lake, the ducklake extension handles DuckLake, and Lance is also supported. Implementing these as native extensions rather than external bindings lets DuckDB apply complex filter pushdowns and manage memory carefully during scans (duckdb.org/docs/current/lakehouse_formats, as of 2026-07-11). The Iceberg extension can also connect to Iceberg REST catalogs, such as AWS Glue, Unity-style, or Lakekeeper services, so that DuckDB resolves tables through the same catalog a cluster engine would use (duckdb.org iceberg REST catalog documentation, as of 2026-07-11). Version 1.5.3 extended the Iceberg support with full MERGE INTO against Iceberg and bucket and truncate partition transforms.

Querying an Iceberg table from DuckDB requires only loading the extension and pointing a scan at the table. The engine then applies projection and predicate pushdown to the underlying Parquet files.

INSTALL iceberg;
LOAD iceberg;

-- Attach a REST catalog, then scan an Iceberg table directly
ATTACH 'warehouse' AS lake (
  TYPE iceberg,
  ENDPOINT 'https://catalog.example.com/api/catalog'
);

SELECT region, sum(amount) AS revenue
FROM lake.sales.orders
WHERE order_date >= DATE '2026-07-01'   -- predicate pushed to file pruning
GROUP BY region;                        -- only 3 columns read (projection)

This model is well matched to a specific set of situations: a developer’s laptop, a notebook exploring a dataset, a continuous-integration job validating a data transformation, a small serverless function, and small-to-medium datasets generally. In each case the value is the absence of a cluster to provision and pay for. DuckDB can query an Iceberg or Delta table sitting in S3 directly, from a script, with no distributed infrastructure in between. It is not a replacement for a distributed engine on terabyte-scale joins, because a single machine cannot shuffle data across a fleet, but for a large share of everyday analytical questions the data fits and the cluster is unnecessary.

DuckLake and the Metadata-in-a-Database Shift

DuckLake is a lakehouse format that relocates where table metadata lives. In the prevailing design, exemplified by Iceberg, a table’s metadata — its snapshots, manifests, and file lists — is stored as a chain of files on the same object storage as the data. DuckLake instead stores all of that lakehouse metadata in a SQL catalog database, which may be SQLite, PostgreSQL, or DuckDB, while the data files remain Parquet on object storage (ducklake.select/2026/04/13/ducklake-10; ducklake.select/faq, as of 2026-07-11). The motivation is that many metadata operations — listing snapshots, resolving the current table version, planning which files to read — are exactly the transactional lookups that relational databases perform efficiently, whereas doing them through a tree of small files on object storage incurs many round trips.

DuckLake v1.0, described as production-ready with a backward-compatibility guarantee, was released on 2026-04-13, with a v1.1 specification expected in September 2026 (ducklake.select/2026/04/13/ducklake-10, as of 2026-07-11). Notably, the interoperability path runs through Iceberg: DuckDB’s Iceberg extension can perform a metadata-only copy of Iceberg metadata into DuckLake, after which the same underlying data files can be queried as DuckLake tables. DuckLake is treated here as a supporting anchor rather than a fourth peer engine, because its significance is architectural: it illustrates a broader movement of the catalog boundary from files on object storage into a database, which reshapes how any engine discovers and plans over lakehouse tables.

Pushdown and Caching: How Engines Avoid Reading Data

All three engines share the same fundamental challenge — object storage is slow relative to local memory — and their answers, though implemented differently, follow the same two principles. The first is to avoid reading data that a query cannot use, through pushdown. The second is to avoid re-reading data that has already been fetched, through caching. Understanding these two mechanisms clarifies why cache-warm and cache-cold performance can differ by a large margin, and why an engine’s steady-state behavior matters more than its first-query latency.

The Pushdown Flow

Pushdown proceeds in layers, and each layer that eliminates data spares every layer below it. A query’s filter first prunes partitions using the table format’s partition metadata, so that whole directories of files are skipped. Within the surviving partitions, file-level statistics eliminate individual data files whose value ranges cannot match the filter. Within a file that must be opened, Parquet’s row-group statistics allow the reader to skip row groups, and projection pushdown ensures that only the referenced columns are decoded. What reaches the engine’s operators is therefore a small fraction of the table. The detail of what these statistics contain, and how row groups and encodings are laid out, belongs to the Parquet and Arrow internals discussion; the point here is that all three engines depend on this same cascade, which is why the table and file format the data lands in — often the output of a pipeline such as the one described in the InfluxDB-to-Iceberg data pipeline — directly governs how effective any engine’s pushdown can be.

Caching Layers Compared

Pushdown reduces how much data a query reads; caching reduces how often that reading crosses the network. The three engines place a cache in front of object storage in structurally similar ways but with different scopes. Trino uses a native file-system cache for its Delta Lake, Hive, and Iceberg connectors, and can front object storage with Alluxio as a distributed cache. StarRocks provides a block-level Data Cache in its Compute Nodes and Backends, complemented in 4.0 by metadata caching that reduces cloud API calls, and its shared-data mode is explicitly designed to keep a warm local cache over remote data. DuckDB, running in a single process, benefits from operating-system page caching and its own buffer management, and reads through native extensions tuned for memory efficiency, but it has no distributed cache tier because it has no distribution.

Choosing an Engine

The three engines map cleanly onto three families of workload, and the selection is usually determined by the shape of the workload rather than by raw speed. The following table summarizes the architectural properties that drive the decision. All performance characterizations are qualitative, in keeping with the benchmark caveat stated below.

When Each Engine Fits

Trino is the appropriate choice when the requirement is heterogeneous, federated ad-hoc SQL across many sources: exploring a data lake, or standing up a shared query gateway over Iceberg, Delta, and Hive tables alongside relational and NoSQL catalogs. Its storage and compute are fully decoupled, and it scales by adding workers. It is weaker as an always-on, low-latency serving layer unless paired with a warm file-system or Alluxio cache, so a team that needs a single engine for wide-ranging exploration across systems is its natural user.

StarRocks is the appropriate choice for interactive, sub-second BI and dashboards on the lakehouse, particularly under high concurrency. Its cost-based optimizer, materialized views, and Data Cache accelerate repeated queries over Iceberg and Hive tables, and its shared-data mode preserves storage-compute separation while keeping a warm local cache. A team serving many concurrent dashboard users from lakehouse tables, where the same aggregates recur, is its natural user. Interactive serving is a different problem from batch pipelines; the boundary between low-latency serving engines and batch processing is examined in the guide to streaming versus batch data-processing architectures.

DuckDB is the appropriate choice for single-node embedded analytics: developer laptops, notebooks, continuous-integration jobs, small-to-medium datasets, and serverless functions that need to query Iceberg, Delta, or DuckLake tables directly without a cluster. It is bounded by one machine’s memory and cores and performs no distributed shuffle, so it is not a candidate for very large distributed joins, but for the large fraction of analytical work that fits on one machine it removes the operational cost of a cluster entirely.

These regions are not mutually exclusive in practice. A single organization commonly runs more than one: DuckDB in development and CI, Trino as a federated exploration gateway, and StarRocks behind the production dashboards. Because all three read the same lakehouse tables, using several is a matter of pointing each at the same object storage rather than maintaining separate copies of the data, which is precisely the flexibility the storage-compute separation was intended to provide.

Frequently Asked Questions

Can Trino, StarRocks, and DuckDB query the same Iceberg tables at once?

Yes. Because a lakehouse separates storage from compute, the Iceberg tables live in object storage independently of any engine, and all three can read them concurrently. Trino uses its Iceberg connector, StarRocks uses an external catalog, and DuckDB uses its native Iceberg extension, optionally resolving tables through a shared REST catalog. No engine owns the data, so adding one is a configuration change rather than a data migration.

Is DuckDB a replacement for Trino or StarRocks?

Not for distributed workloads. DuckDB runs in a single process and is bounded by one machine’s memory and cores, with no distributed shuffle, so it cannot spread a large join across a cluster the way Trino or StarRocks can. For datasets that fit on one machine — a common case in development, notebooks, and continuous integration — it removes the need for a cluster entirely and queries lakehouse tables directly, which is a genuine substitute for a cluster in those situations but not in large distributed ones.

Why does the same query run much faster the second time?

Because of caching. On the first execution, an engine fetches data files from object storage across the network. Trino can retain them in its file-system or Alluxio cache, StarRocks in its block-level Data Cache, and DuckDB in process and operating-system buffers. Subsequent queries that touch the same files read them from the local cache instead of object storage, which is substantially faster. This is why a benchmark must state whether the cache was warm or cold; cold-start latency is not representative of steady-state behavior.

What problem does DuckLake solve compared with Iceberg?

DuckLake stores lakehouse metadata — snapshots, manifests, and file lists — in a SQL catalog database such as SQLite, PostgreSQL, or DuckDB, rather than as a chain of small files on object storage, while keeping the data files as Parquet on object storage. Metadata operations such as resolving the current table version become transactional database lookups instead of multiple object-storage round trips. DuckLake v1.0, released on 2026-04-13, is described as production-ready, and Iceberg metadata can be copied into DuckLake so the same data files are queryable as DuckLake tables.

How do materialized views make StarRocks fast on the lakehouse?

A materialized view is a precomputed, stored result of a query. StarRocks supports partition-aligned materialized views over Iceberg and Hive tables that refresh incrementally, recomputing only the changed partitions, and its cost-based optimizer transparently rewrites an incoming query onto an eligible view without the author referencing it. A recurring scan-and-aggregate becomes a lookup. The vendor reports speedups of up to 10 to 100 times on eligible queries, which is a self-reported and workload-dependent figure.

References

• Trino. Trino Concepts: Architecture, Coordinator, Workers, Connectors, and Catalogs. Trino Software Foundation, as of 2026-07-11.
• Trino. File System Caching for Object Storage Connectors and Alluxio file-system support. Trino Software Foundation, as of 2026-07-11.
• StarRocks. StarRocks Architecture: Frontend, Backend, and Compute Nodes. Linux Foundation, as of 2026-07-11.
• StarRocks. StarRocks 2025 Year in Review (4.0 release, materialized views, Data Cache). StarRocks, 2025 (vendor self-reported figures), as of 2026-07-11.
• DuckDB. Lakehouse Formats: Iceberg, Delta, DuckLake Extensions and New Iceberg Features in v1.5.3. DuckDB, as of 2026-07-11.
• DuckLake. Announcing DuckLake v1.0. DuckLake, 2026-04-13, as of 2026-07-11.

Conclusion

Trino, StarRocks, and DuckDB are not three answers to the same question but three answers to three different questions, unified only by the lakehouse substrate they read. Trino’s coordinator-and-worker MPP architecture and its many-catalog federation make it a strong general engine for ad-hoc SQL across heterogeneous sources, provided a caching layer is added when low latency matters. StarRocks’ frontend, backend, and compute-node design, combined with a cost-based optimizer, transparently rewritten materialized views, and a block-level Data Cache, targets interactive high-concurrency serving on the lakehouse, with a shared-data mode that separates storage from compute while retaining a warm local cache. DuckDB’s single-node, in-process model, with native Iceberg, Delta, and DuckLake extensions, brings lakehouse analytics to a laptop, a notebook, or a serverless function without any cluster, at the cost of being bounded by one machine.

The most durable guidance is to treat the engine as a component chosen per workload rather than a platform-wide commitment. Because storage and compute are separated, an organization can run all three over the same tables, matching the engine to the shape of each workload — embedded, federated, or interactive — rather than forcing every query through one engine. The emergence of DuckLake, which moves lakehouse metadata into a SQL catalog database, is a reminder that even the boundary between engine and catalog is still being redrawn, and that the compute tier of the lakehouse remains one of the more active areas of data-engineering design. An engineer who understands each engine’s architecture and its cache and pushdown behavior, rather than a single benchmark number, is positioned to make that selection correctly as the tooling continues to evolve.