Executive Summary
Choose the table format and the catalog before the engine. Every engine you add later has to read and write through them.
A data lakehouse platform stores tables in an open format on cloud object storage and runs SQL analytics, data engineering and machine learning against that one copy. It combines the low-cost storage of a data lake with the transactions, schemas and SQL performance of a data warehouse.
Choose a data lakehouse platform on four things: the table format it writes (Apache Iceberg, Delta Lake or Apache Hudi); the catalog that records each table’s current state and who may use it; which compute engines besides the vendor’s own can read and write those tables; and what the price meter counts.
The platforms divide by the product they started from: a Spark platform built around Delta Lake, cloud warehouses that added open Iceberg tables, a SaaS analytics suite over one lake, a cloud provider’s storage and query services, query engines that read open tables where they sit, and a hybrid platform for data centers and clouds. Settle the format and the catalog first, because every engine you add later has to use them.
What Is a Data Lakehouse Platform?
A data lakehouse keeps data in open file and table formats on object storage and adds what a warehouse gives analysts: transactions, schemas, access control and fast SQL. Storage and compute are separate, so several engines can work on the same tables and each is paid for only while it runs.
The table format is what turns a folder of Parquet files into a table with transactions and history. Apache Iceberg describes Iceberg as a high-performance format for huge analytic tables that makes it possible for engines like Spark, Trino, Flink, Presto, Hive and Impala to safely work with the same tables, at the same time. Apache Iceberg states that time travel enables reproducible queries that use exactly the same table snapshot, or lets users easily examine changes.
Delta Lake describes itself as an open-source storage framework for a format-agnostic lakehouse architecture with compute engines including Spark, PrestoDB, Flink, Trino, Hive, Snowflake, Google BigQuery, Athena, Redshift, Databricks and Azure Fabric. Delta Lake states that it is an independent open-source project and not controlled by any single company. Apache Hudi describes itself as an open data lakehouse platform, with an open table format purpose-built for high performance writes on incremental data pipelines and fast query performance.
A lakehouse and a cloud data warehouse now overlap. Most warehouses read open tables, and most lakehouse platforms include a SQL warehouse engine. For a buyer, the difference is who holds the storage account and the catalog. If the vendor holds both, the data leaves only through that vendor’s export and interoperability features.
This guide covers platforms bought to hold and process open tables. Warehouses evaluated mainly as SQL engines are compared in the cloud data warehouse guide.
Which Compute Engines Run on a Data Lakehouse?
Several, on the same tables. A SQL engine for dashboards, Spark for pipelines and a streaming engine can each work on one copy of the data, as long as each can read the table format and reach the catalog. Databricks states that it is built on Apache Spark, which enables a massively scalable engine that runs on compute resources decoupled from storage.
Lakehouse compute engines fall into three groups. Distributed processing engines such as Apache Spark and Apache Flink run pipelines, streaming and feature engineering. Massively parallel SQL engines serve dashboards and ad hoc queries. Trino describes itself as a highly parallel and distributed query engine, built from the ground up for efficient, low latency analytics. Trino states that it can access data from multiple systems within a single query, such as log data in S3 object storage joined with customer data in a MySQL relational database. Engines built for one platform are the third group. Databricks describes Photon as its native vectorized query engine for SQL workloads, DataFrame API calls, ETL pipelines, and stateless streaming workloads. Dremio states that its Arrow-based query engine processes Iceberg data natively, with no format conversion.
The catalog decides which engines can reach a table. It records where each table’s current metadata is and commits each write, so every table needs exactly one catalog that all engines write through. The Iceberg REST catalog API is the common interface. Apache Polaris describes itself as an open-source, fully-featured catalog for Apache Iceberg that implements Iceberg's REST API.
Write access from outside engines is where platforms differ. Databricks documentation shows that Iceberg REST catalog clients can read and write managed Iceberg tables, but can only read foreign Iceberg tables and Delta tables with Iceberg reads enabled. Snowflake states that external engines can read and write Snowflake-managed Iceberg v2 and v3 tables through the Horizon Iceberg REST Catalog API. Google states that Apache Iceberg tables managed using the Lakehouse Iceberg REST catalog provide read and write interoperability between BigQuery, Google Cloud Managed Service for Apache Spark and Iceberg-compatible OSS engines such as Spark, Trino and Flink.
Converting table metadata between formats is a fallback for engines that cannot read your primary format. Apache XTable states that it is not a new or separate format, and that it provides abstractions and tools for the translation of lakehouse table format metadata. Apache XTable describes Delta Lake UniForm as a one-directional conversion from Delta Lake to Apache Hudi or Apache Iceberg. Delta Lake states that with Delta Universal Format (UniForm), Delta tables can be read with Iceberg and Hudi clients.
| Engine type | Typical work | Examples | Ask the vendor |
|---|---|---|---|
| Distributed processing | Pipelines, streaming, feature engineering | Apache Spark, Apache Flink | Which runtime versions are supported, and whether it writes your table format natively |
| Massively parallel SQL | Dashboards, ad hoc SQL, queries across sources | Trino, Presto, a platform’s SQL warehouse | Whether it applies the catalog’s row and column policies |
| Platform-native engine | SQL and pipelines inside one platform | Vectorized engines built for one platform | Which operations fall back to a slower path, and how the engine is metered |
| Single-node and embedded | Notebooks, local analysis, small jobs | Python data libraries, embedded SQL engines | Whether it reads through the catalog with credentials the catalog issues |
What Should a Data Lakehouse Platform Do?
Five jobs: store open tables, govern them through a catalog, run more than one engine on them, keep them fast, and share them without copies. Most platforms do all five. They differ in which one they were built around.
Tables on object storage slow down as small files and old snapshots pile up, so compaction and snapshot expiry have to run on a schedule. AWS states that S3 Tables continuously optimize Iceberg tables through compaction, snapshot management, and unreferenced file removal. Google states that routine Iceberg maintenance like compaction, clustering, and garbage collection can be offloaded to Google Lakehouse. Starburst states that LakeOps runs Iceberg compaction, snapshot expiry, and orphan file removal on a dedicated serverless engine that never touches your cluster. Ask who pays for that compute, and whether it runs on tables that another engine wrote.
Check whose cloud account holds the files, because that decides who restores them. Snowflake states that with external volume storage the files are in cloud storage you manage, you are responsible for data protection and recovery, Snowflake does not provide Fail-safe, and your cloud provider bills you for storage.
Data that already sits elsewhere can be read where it is. Microsoft states that you can use shortcuts for OneLake, Azure Data Lake Storage, Azure Blob storage, Amazon S3 and S3 compatible sources, Iceberg-compatible sources, Microsoft Dataverse and on-premises sources. Cloudera states that on-premises data can be accessed using cloud compute without copying or moving the data in the cloud. Ask what each source costs to read, and whether caching or egress charges apply.
Access policies must hold for every engine, not only the vendor’s own. Ask whether row filters and column masks apply when an outside engine reads a table through the catalog, and whether the catalog issues short-lived storage credentials or expects each engine to hold its own.
| Capability | What to test | Why it matters |
|---|---|---|
| Table formats | Native read and write of Iceberg, Delta Lake or Hudi, and which versions | Decides which engines can join later |
| Catalog | An Iceberg REST endpoint, credential vending, and write access for outside engines | Controls interoperability |
| Access control | Row filters and column masks, applied in outside engines as well | A policy that stops at one engine leaks data through another |
| Table maintenance | Compaction, clustering, snapshot expiry and orphan file removal | Query speed and storage cost |
| Engines | SQL, Spark, streaming and machine learning on the same tables | Removes copies between systems |
| Ingestion | Streaming and change data capture written straight into tables | Freshness of dashboards and features |
| Sharing | Live tables shared with other accounts, clouds and organizations | Replaces extract files |
| Deployment | Your cloud account, vendor-hosted SaaS, or your data center | Residency, and who operates it |
Vendors in Data Lakehouse Platforms
Representative vendors include AWS Athena / EMR + S3 Tables, Cloudera, Databricks, Dremio, Google BigQuery / BigLake (Lakehouse for Apache Iceberg), Microsoft Fabric, Snowflake and Starburst. The list is alphabetical, is not a ranking, and is not for sale. How we choose vendors
Data lakehouse platforms and their competitors divide by the product they started from. That starting point sets the default table format, who holds the catalog and where compute runs.
The Spark platform built around Delta Lake also serves Iceberg tables through its catalog. Databricks states that its lakehouse uses Delta Lake, an optimized storage layer that supports ACID transactions and schema enforcement, and Unity Catalog, a unified, fine-grained governance solution for data and AI. Databricks states that the Apache Iceberg REST catalog lets supported clients, such as Apache Spark, Apache Flink, and Trino, read from and write to Unity Catalog-registered Iceberg tables on Databricks.
Cloud warehouses that added open tables keep their own engine and let tables live in open formats. Snowflake states that Apache Iceberg tables for Snowflake combine the performance and query semantics of typical Snowflake tables with external cloud storage that you manage. Snowflake describes Snowflake Open Catalog as a managed service for Apache Polaris. Snowflake states that customers who have not previously created a Snowflake Open Catalog account cannot sign up for one, and that new customers should use Snowflake Horizon Catalog for Apache Iceberg tables. Google Cloud now names the product Lakehouse for Apache Iceberg (formerly BigLake). Google states that BigQuery can query Iceberg and Delta Lake directly.
The SaaS analytics suite puts every workload over one lake. Microsoft states that Fabric is delivered as a software-as-a-service (SaaS) platform and uses OneLake as a centralized, logical data lake for storing and accessing data across all workloads. Microsoft states that OneLake is built on Azure Data Lake Storage and stores tables in Delta Parquet or Iceberg format, two open standards that any tool can read. Microsoft states that OneLake generates virtual Delta Lake metadata for Iceberg tables written to it or reached through a shortcut, and that Delta Lake tables include virtual Iceberg metadata for Iceberg readers.
A cloud provider’s storage and query services are bought separately and combined. AWS states that S3 Tables expose the Iceberg REST Catalog API, so they work with Iceberg-compatible engines including Spark, Trino, Flink, Athena, Redshift and Snowflake. AWS states that Amazon EMR lets customers deploy Apache Spark, Trino, Apache Flink, or Apache Hive, and supports open table formats like Iceberg, Hudi and Delta.
Query engines on open tables read data where it sits and bring their own catalog or use yours. Dremio states that Open Catalog (Apache Polaris) enables read/write across any Iceberg REST engine. Dremio states that Autonomous Reflections observe query patterns and accelerate queries, with no tuning required. Dremio states that Dremio Cloud is fully managed on AWS, and that Dremio Enterprise is for organizations that need full control, whether on-premises, Kubernetes, or their own cloud environment. Starburst describes Galaxy as Starburst, fully managed, on any cloud. Starburst states that Starburst Enterprise runs in a private cloud, hybrid, or on-premises with full control over residency and security. Starburst states that Starburst Enterprise is built on Trino and is air-gap ready.
The hybrid platform runs the same lakehouse in a data center and in public clouds. Cloudera describes an open-source, open standard-based lakehouse powered by Apache Iceberg. Cloudera states that Apache Iceberg can be deployed on premises or in the public cloud with the same experience, same data services and unified metadata. Cloudera states that you can optimize cloud data warehouse spend by running any engine, including Cloudera engines, open-source engines, or any Iceberg-compatible third-party engines, on Cloudera's Open Data Lakehouse.
Other products compete for parts of this budget. Onehouse states that the Onehouse Platform deploys in your own VPC, on any cloud. Onehouse states that it created Apache Hudi and Apache XTable. Oracle states that Autonomous AI Lakehouse deploys on OCI, AWS, Azure, or Google Cloud and can query data in any object store using open formats such as Apache Iceberg. Oracle states that AI Lakehouse runs on one multi-model engine rather than stitched-together services. Qlik states that Upsolver is now Qlik Open Lakehouse, a feature within Qlik Talend Cloud. Qlik states that Upsolver ingests streaming, database, and file data into Apache Iceberg and includes hands-off table management and optimization.
| Vendor | Approach | Where it fits |
|---|---|---|
| AWS Athena / EMR + S3 Tables | Cloud provider lake services | Managed Iceberg storage in S3 Tables, queried with Athena, EMR or other Iceberg engines |
| Cloudera | Hybrid platform for data center and cloud | An Iceberg lakehouse with the same data services on premises and in public clouds |
| Dremio | Query engine on open tables | An Iceberg-native SQL engine with an Apache Polaris catalog, as a managed service or self-managed |
| Starburst | Query engine on open tables | Trino as a managed service (Galaxy) or self-managed (Enterprise), querying many sources |
| Microsoft Fabric | SaaS analytics suite over one lake | Every Fabric workload over OneLake, storing tables as Delta Parquet or Iceberg |
| Databricks | Spark platform on Delta Lake | Spark, Photon and Unity Catalog over Delta Lake, with Iceberg REST access for outside engines |
| Google BigQuery / BigLake (Lakehouse for Apache Iceberg) | Warehouse with open tables | BigQuery and managed Spark on Iceberg tables in a shared REST catalog, with managed table maintenance |
| Snowflake | Warehouse with open tables | Iceberg tables in Snowflake or your own storage, read and written by outside engines through Horizon Catalog |
Eight platforms across six approaches; Snowflake and Google share one, as do Dremio and Starburst. Onehouse, evaluated in the previous edition, is covered in the text above. The approaches were set first and the platforms were then selected for each from the vendors this guide already evaluated. No row in this table is for sale. Oracle and Qlik also sell lakehouse products, and any lakehouse vendor can make its own case in the Spotlight below.
How Are Data Lakehouse Platforms Priced?
Mostly by compute consumed, in each vendor’s own unit, plus object storage that you may pay your cloud provider for directly. Price one workload in every unit: a month of your pipelines, your heaviest dashboard queries and your storage at year-three volume.
Databricks defines a Databricks Unit (DBU) as a normalized unit of processing power on the Databricks Lakehouse Platform used for measurement and pricing purposes. Microsoft describes capacity units (CUs) as units of measure representing a pool of compute power, which is required to run all queries, jobs, or tasks in Fabric. Dremio states that a Dremio Compute Unit (DCU) measures engine runtime and that DCU pricing is time-based, not per query, calculated as engine size × minutes running. Dremio lists Dremio Cloud pay-as-you-go at $0.20 per DCU. Starburst states that its pricing is based on compute usage, the features and support in each tier, and the deployment location, and that credit consumption is the same for all product tiers.
Scan-based pricing charges for data read rather than engine time. Google lists BigQuery on-demand queries at $6.25 per tebibyte, with the first 1 TiB per month free. AWS prices an Athena example query that scans 3 TB at $5 per TB, or $15. Partitioning, columnar formats and compaction reduce how much each query reads.
Catalog and table services carry their own meters. Snowflake states that Horizon Iceberg REST Catalog API requests are billed as 0.5 credit per million calls, with billing scheduled to begin in the second half of 2026. Google states that Lakehouse (BigLake) pricing is based on table management, metadata storage and metadata access. AWS states that with S3 Tables you pay for storage, requests, and an object monitoring fee per object stored in table buckets. Onehouse states that it deploys in your VPC or any Kubernetes cluster, priced pay as you go or as a flat yearly fee.
| Meter | You pay for | Grows with | Where it goes wrong |
|---|---|---|---|
| Compute unit | Engine time, sized by cluster or capacity | Pipelines, concurrency and always-on warehouses | Clusters left running, and capacity sized for the peak |
| Data scanned | Bytes read by each query | Query volume and table layout | Unpartitioned tables and queries that read every column |
| Reserved capacity | A block of compute for a month or a year | The size of the commitment | Idle capacity paid for anyway |
| Storage | Object storage, sometimes billed by your cloud provider | Data volume and retained snapshots | Snapshots that are never expired |
| Table and catalog services | Maintenance compute, metadata storage and catalog calls | Table count and write frequency | Streaming writes that create many small files |
How Do You Move to a Data Lakehouse?
Decide the table format and catalog before moving any workload, because changing them later means rewriting every table. Pipelines and dashboards can then move one domain at a time. The phases below assume a pilot of about three months.
Choose the primary table format and the catalog, and decide whose cloud account holds the files. List every engine that must read or write the tables, now and in three years.
Load two or three subject areas at production volume. Run your pipelines and your heaviest dashboard queries, write from two engines, and record the compute units each workload consumed.
Apply access policies through the catalog and check them from every engine. Schedule compaction and snapshot expiry, and restore a table from a snapshot to prove recovery works.
Move workloads one domain at a time. Reconcile results against the old warehouse or lake, then retire the old copy so storage is not paid for twice.
What should you ask vendors about Data Lakehouse Platforms?
Put these questions in the RFP, and ask for each answer to be shown on your own data with an engine you already run.
-
Do most of your workloads already run on Spark, or do data scientists need notebooks on the same tables?Yes Shortlist platforms built on Spark, and test their SQL engine on your dashboards.No Start from your SQL workload, and test which platforms keep tables open to Spark later.
-
Must data or compute stay in your own data center?Yes Shortlist platforms that run on premises, and compare them on the same hardware.No Compare where the files live: your cloud account or the vendor’s.
-
Will more than one engine write to the same tables?Yes Require an Iceberg REST catalog with write access for outside engines, and test concurrent writes in the pilot.No Require read access for outside engines through the catalog, so a second engine can be added later.