A data lakehouse puts warehouse-style structure, including transactions and schema enforcement, on top of low-cost data lake storage using an open table format such as Delta Lake or Apache Iceberg. It aims to give you a lake's flexibility and a warehouse's reliability in one platform, so analysts and data scientists work from the same copy of the data.
If you have read our post on data lake vs data warehouse, you know the trade-off. A warehouse gives you structure and speed. A lake gives you flexibility and cheap storage. The data lakehouse is an attempt to get both, and the rest of this post explains how it does that, who has adopted it, and when a plain warehouse is still the better choice.
Data Lake vs Data Warehouse vs Data Lakehouse
The quickest way to place the data lakehouse is next to the two things it combines.
| Data lake | Data warehouse | Data lakehouse | |
| Data types | Raw files of any type | Cleaned, structured tables | Any type, with structured tables on top |
| Schema | Applied when you read | Defined before you write | Enforced by the table format, evolves over time |
| Transactions | None on plain files | Full ACID | ACID through the transaction log |
| Typical users | Data engineers, data scientists | Analysts, business users | Both, on one copy |
| Storage | Object storage, low cost | Managed by the warehouse, higher cost | Object storage, low cost |
| Maintenance | Files pile up unless managed | Handled by the platform | Compaction and cleanup are your job unless the platform does it |
| Examples | ADLS Gen2, Amazon S3 | Snowflake, Fabric Warehouse, BigQuery, Redshift | Databricks, Fabric Lakehouse on OneLake, Snowflake Iceberg tables |
Where the Idea Comes From
Databricks described the pattern in a January 2020 blog post. The clearest technical description is a CIDR 2021 paper by researchers at Databricks, UC Berkeley and Stanford: Michael Armbrust, Ali Ghodsi, Reynold Xin and Matei Zaharia. It reports a Parquet-based data lakehouse competitive with popular cloud data warehouses on the TPC-DS benchmark.
The paper's argument is worth knowing because it explains why the idea caught on. Companies were running a lake for raw data and machine learning, and a warehouse for BI, and paying to copy data between them. Every copy was a pipeline to maintain and a place for the two systems to disagree. The lakehouse proposal was to make the lake reliable enough that the warehouse copy was no longer needed.
Data Lakehouse Architecture
A data lakehouse adds a metadata layer on top of storage you already understand. The Delta Lake documentation describes the pieces, and the same shape applies to Apache Iceberg and Apache Hudi.
- Storage. Parquet files hold the data, in the same open, columnar format a lake already uses, on object storage such as ADLS Gen2 or S3.
- Table format. A transaction log records which Parquet files make up each table and every change to them. This is what gives the data lakehouse its warehouse-style reliability: atomic writes, schema enforcement, time travel, and the ability to update and delete rows without rewriting the lake.
- Statistics. Column statistics let a query engine skip files it does not need. Per the Delta Lake optimization docs, data skipping information is collected automatically when you write data to a Delta table.
- Engines. Spark, SQL endpoints, Power BI and Python libraries all read the same tables through the table format, so there is no copy per engine.
- Catalog. A catalog such as Unity Catalog, the Fabric OneLake catalog or AWS Glue holds the list of tables, their owners and their permissions.
The part that is new is the table format. The storage, the engines and the catalog existed before. What the lakehouse architecture adds is a log that makes a folder of Parquet files behave like a managed table.
Who Is Using This Today
- Databricks. It built its platform on Delta Lake after describing the pattern in 2020, and most of the vocabulary comes from there.
- Microsoft Fabric. Every Fabric tenant stores its data in OneLake as Delta Parquet or Iceberg tables, and a Fabric lakehouse is one of the standard item types. See What Is OneLake? for how the storage layer works.
- Snowflake. It made Iceberg tables generally available in June 2024 and expanded its Iceberg support in April 2025, so a Snowflake warehouse can now sit on open-format tables in your own storage.
- Oracle. It announced its Autonomous AI Lakehouse on 14 October 2025. The product is built on Apache Iceberg for multicloud data access.
Four of the largest data vendors now ship a lakehouse, and each builds it on an open table format, Delta Lake or Apache Iceberg. That is why "open table format" matters more than any one vendor's name.
The Data Lakehouse in Microsoft Fabric
Since most of our clients run Microsoft, it is worth being specific. In Fabric, a lakehouse is an item you create in a workspace. It has a Tables area, where Delta tables live, and a Files area for anything else. Notebooks write to it with Spark. A SQL analytics endpoint is created with it automatically, so analysts can query the Delta tables with T-SQL and Power BI can read them in Direct Lake mode without importing.
Fabric also has a separate Warehouse item. Microsoft's decision guide sets out the difference: the warehouse supports full T-SQL, including inserts, updates, deletes and multi-table transactions, while the lakehouse SQL endpoint is read-only for T-SQL and expects writes to come through Spark. Both store their tables in OneLake in Delta format, so a Fabric warehouse is itself built on lakehouse storage. The choice between them is mostly about who writes the data and in what language. Our Microsoft Fabric consulting page covers how we set these up.
Data Lake vs Lakehouse
If you already have a data lake, the question is whether adding a table format is worth the effort.
A plain lake is a folder structure. It stores files and nothing else. Two jobs writing to the same folder can leave it half-updated, a schema change in a source system silently produces files that do not match the old ones, and there is no way to delete one customer's rows without rewriting the file they sit in.
A lakehouse fixes those specific problems. Writes are atomic, the schema is checked on write, and row-level deletes and updates are supported. It does not change where the data lives or what it costs to store. For a lake that only feeds machine learning experiments, the upgrade may not be needed. For a lake that feeds reports people act on, it usually is.
When to Use a Data Lakehouse
In our view a lakehouse earns its place when most of the following are true.
- The data is mixed. Tables from ERP and CRM systems sit next to logs, documents, images or sensor feeds that will never fit a warehouse schema.
- BI and machine learning need the same data. A lakehouse lets both read one governed copy instead of a lake for one team and a warehouse for the other.
- The team writes Spark or Python. Lakehouse writes happen in code. A team that only writes SQL will find a warehouse more natural.
- Volume makes a second copy expensive. If the warehouse copy of the lake is the largest line on the bill, a lakehouse removes it.
- You want open formats. Delta and Iceberg tables can be read by any engine, which keeps a future platform change cheap.
- Multi-table transactions are rare. Reporting workloads rarely need them. Operational workloads often do.
The pattern we see at mid-size companies is simpler than the vendor material suggests. Most of them start with a lakehouse as the landing zone and a modelled layer of Delta tables on top of it for reporting. A separate warehouse item is added only when a finance or operations process needs the transaction guarantees.
Where a Dedicated Warehouse Still Wins
A lakehouse is a trade-off. Microsoft's Fabric decision guide sends workloads that need multi-table transactions to a warehouse. It lists full DQL, DML and DDL T-SQL support for the warehouse, against full DQL, no DML and limited DDL on the lakehouse SQL analytics endpoint.
A lakehouse also has more moving parts: an engine like Spark alongside the table format, rather than one managed system. Left unmaintained, it can develop the small-file and metadata bloat problems a lake has always had. Compaction, vacuuming old file versions and statistics refreshes are jobs someone has to schedule, unless the platform runs them for you.
Vendor and trade-press coverage also suggests a dedicated warehouse can outperform an untuned lakehouse on complex BI workloads with many simultaneous queries. We have not found an independent study that quantifies this, so treat it as a direction. If a warehouse fits your reporting, our data warehousing services page explains how we build them.
Frequently Asked Questions
What is a data lakehouse? A data lakehouse is a data platform that stores data as open-format files on low-cost object storage and adds a table format such as Delta Lake or Apache Iceberg on top, so the files behave like reliable database tables with transactions and schema enforcement.
Is a lakehouse just a rebranded data lake? No. The open table format on top adds transaction guarantees and schema enforcement that a plain lake lacks.
What is the difference between a data lake and a lakehouse? A lake stores files. A lakehouse adds a table format and transaction log on top of those files, so queries get warehouse-style reliability.
Do we need Databricks to use a lakehouse? No. Microsoft Fabric, Snowflake and Oracle all support lakehouse architecture through open table formats.
Does Microsoft Fabric use this architecture? Yes, through OneLake. Every Fabric lakehouse and warehouse stores its tables in OneLake as Delta Parquet. See our guide to OneLake.
Is Databricks a data warehouse or a lakehouse? Databricks describes its platform as a lakehouse. Its SQL warehouse product runs on the same Delta tables rather than on a separate warehouse store.
Is a lakehouse cheaper than a warehouse? Storage is cheaper, because it is plain object storage. Compute costs depend on how well the lakehouse is tuned and how many queries run against it.
What is an AI data lakehouse? A vendor term for a lakehouse packaged with machine learning tooling, vector search and model serving on the same storage. Oracle's and Databricks' products use it. The storage architecture is the same.
What is the catch? More moving parts, and performance that depends on maintenance a managed warehouse handles for you.
Not sure whether a lakehouse fits your current setup? Talk to Alphabyte or see our Microsoft Fabric consulting page.