What Is a Data Lakehouse? How It Works and When to Use One

For years, companies kept 2 separate data systems. A data warehouse held clean, structured data for reports and dashboards. A data lake held everything else, raw files, logs, images and event streams, for data science and machine learning. Data was copied back and forth, the 2 copies drifted apart and teams argued about which numbers were right.

The data lakehouse is an attempt to end that split. This guide explains what a lakehouse is, how it actually works under the hood and how to decide whether it’s the right architecture for your business.

What a data lakehouse is

A data lakehouse is an architecture that keeps your data in cheap, open cloud object storage, the way a data lake does, and adds the reliability and performance features you’d expect from a data warehouse.

The term was popularized by a 2021 research paper presented at the CIDR database conference by authors from Databricks, UC Berkeley and Stanford. The paper argued that the classic 2-tier setup, a lake plus a separate warehouse, causes stale data, reliability problems, extra cost and vendor lock-in. Its proposed alternative: build warehouse-style management directly on top of open file formats like Apache Parquet in the lake.

In short:

• From the lake, you get low-cost storage, support for any data type and open formats that many tools can read.
• From the warehouse, you get transactions, schema rules, data quality controls and fast SQL for BI.

If you need a refresher on the 2 original architectures, read our data lake vs data warehouse comparison first.

How a lakehouse works

A lakehouse has 4 main layers. The key innovation is the second one.

1. Object storage

Data files sit in cloud object storage such as Amazon S3, Azure Data Lake Storage or Google Cloud Storage, usually in the open Parquet columnar format. Storage is cheap and scales without limit for most practical purposes.

2. Open table format

This is the metadata layer that turns a folder of files into a reliable table. The main open table formats are:

• Delta Lake, an open-source storage framework hosted by the Linux Foundation. Its project site lists ACID transactions, time travel, schema enforcement and evolution, and audit history.
• Apache Iceberg, which describes itself as “a high-performance format for huge analytic tables.” It supports schema evolution without rewriting tables, time travel and rollback, and works with engines including Spark, Trino, Flink and Presto.
• Apache Hudi, a third open format often used for frequent updates and incremental processing.

These formats track which files belong to each version of a table. That’s what makes updates, deletes and concurrent reads and writes safe on plain object storage.

3. Compute engines

Because the data is stored in open formats, several engines can query the same tables: SQL warehouses for BI, Apache Spark for data engineering and Python notebooks for machine learning. Storage and compute are separate, so you scale and pay for each independently.

4. Catalog and governance

A catalog keeps track of tables, schemas, permissions and lineage. This is where you control who can see what, a critical step for avoiding a “data swamp.”

Key takeaway: A lakehouse isn’t a single product. It’s a pattern: open files in cheap storage, plus an open table format that adds warehouse-grade reliability, plus engines and governance on top.

Lakehouse vs data lake vs data warehouse

The lines have blurred. Major warehouses now read and write open table formats too. Snowflake, for example, supports Apache Iceberg tables stored either in Snowflake or in your own cloud storage. Microsoft Fabric’s OneLake uses Delta Lake as its standard table format and can expose Iceberg tables as Delta and vice versa. So “warehouse or lakehouse” is less of a hard choice than it was a few years ago.

The medallion architecture

Most lakehouses organize data into quality layers, a pattern called the medallion architecture. Microsoft’s Azure Databricks documentation describes 3 layers:

The idea is to improve quality step by step. Raw data is kept for reprocessing and audits, while business users only see the clean gold tables. The data pipelines that move data between layers usually follow an ELT pattern.

Benefits of a data lakehouse

• One copy of the data. BI and data science work from the same tables, so numbers match and you aren’t paying to store and sync duplicates.
• Lower storage cost. Object storage is generally cheaper than proprietary warehouse storage, though compute is where most of the bill usually lands.
• Open formats reduce lock-in. If your data is in Iceberg or Delta, you can change or add engines without a full migration. See our guide on avoiding cloud vendor lock-in.
• Built for AI. Data scientists can read raw and curated data directly, including the unstructured data machine learning often needs.
• Fresher data. Streaming and batch data can land in the same tables, so dashboards don’t wait for an overnight copy.
• History and recovery. Time travel lets you query or restore earlier versions of a table after a bad load.

Drawbacks and trade-offs

• More moving parts. You’re choosing storage, a table format, engines and a catalog. Managed platforms hide much of this, but someone still has to understand it.
• Maintenance. Tables need housekeeping such as compacting small files. Some platforms automate this; others leave it to you.
• Skills. Lakehouses lean on data engineering skills like Spark, Python and pipeline design. Read our guide on how to become a data engineer to see what that role involves.
• Governance doesn’t come free. Without a catalog, ownership and access rules, a lakehouse can turn into a swamp as easily as a lake.
• Overkill for small data. If your data fits comfortably in a single cloud database or warehouse, a lakehouse may add cost and complexity with little benefit.

Do you need a data lakehouse?

A lakehouse is a strong fit if most of these are true:

• You have both BI reporting and data science or machine learning needs.
• You store a lot of semi-structured or unstructured data, such as logs, events, documents or images.
• Your data volumes are large or growing fast. See what is big data for a quick test.
• You’re paying to copy data between a lake and a warehouse today.
• You want to avoid being tied to a single vendor’s storage format.

A warehouse alone is probably enough if your data is mostly structured, your main use is dashboards and reports, and your team is SQL-first. Our guide to what a data warehouse is covers that path.

Where to start

1. List your workloads. Write down who uses data and how: dashboards, ad hoc SQL, forecasting, machine learning, AI assistants.
2. Check your current platform. Many warehouses and cloud platforms already support open table formats, so you may be able to adopt lakehouse patterns without switching vendors.
3. Pick a table format deliberately. Delta Lake and Apache Iceberg are the most widely supported. Choose based on the engines you use and plan to use.
4. Start with one domain. Move a single area, such as sales or web events, through bronze, silver and gold before migrating everything.
5. Set up governance on day one. Define owners, access rules and naming conventions in your catalog. Our guide to data governance explains the basics.
6. Watch compute costs. Set budgets, auto-suspend idle clusters and track spend by team. FinOps practices help here.

If you’re deciding between the 2 best-known platforms, see our Snowflake vs Databricks comparison.

Conclusion

A data lakehouse combines the low-cost, flexible storage of a data lake with the transactions, schema control and SQL performance of a data warehouse. Open table formats like Delta Lake and Apache Iceberg make it possible, letting BI, analytics and AI share a single copy of your data. It’s a strong choice for growing companies with mixed workloads, but a plain warehouse is still fine for structured, report-focused needs. Start with the workloads, not the buzzword.

For more definitions, visit our glossary.

Sources

• Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics (CIDR 2021) — origin of the lakehouse concept and the problems with 2-tier architectures
• Delta Lake — features of the Delta Lake table format and its Linux Foundation governance
• Apache Iceberg — features of the Iceberg table format and supported engines
• Microsoft Learn: Medallion lakehouse architecture — bronze, silver and gold layers
• Snowflake documentation: Apache Iceberg tables — warehouse support for open table formats
• Microsoft Learn: OneLake Iceberg tables — Delta and Iceberg interoperability in Microsoft Fabric