Data lakehouse
Also known as: lakehouse, lakehouse architecture
A data lakehouse is a data architecture that stores data cheaply in open file formats, like a data lake, but adds the reliable tables, transactions, and fast queries of a data warehouse.
The goal is one copy of data that serves both business reports and machine learning. While 'lakehouse' started as a Databricks marketing term, the open table formats underneath it have reshaped how almost every data platform works.
Data lakehouse, explained at three levels
At home
Imagine a giant storage unit where you throw in boxes of anything (a data lake) versus a tidy library with a catalogue (a data warehouse). A lakehouse is a storage unit with a librarian: cheap space, but organized so you can find things fast.
At work
A lakehouse lets a company keep all its data in one place for reports, dashboards, and AI projects, instead of copying it between separate systems. That cuts storage costs and reduces mismatched numbers.
At home
Data sits in cloud storage as files, often in the Parquet format. A 'table format' such as Delta Lake or Iceberg keeps track of which files make up each table and its history, so many tools can read and update the data safely.
At work
Lakehouses support ACID transactions, schema enforcement, time travel to past versions, and access from many engines, such as Spark, Trino, Snowflake, or Databricks SQL. A shared catalogue manages permissions and table discovery across those engines.
At home
The clever part is separating storage from compute. Files stay put in cheap storage, and different engines spin up to process them as needed. In my opinion, that separation is what makes switching vendors realistic for the first time in analytics.
At work
The catalogue has become the new point of lock-in: Unity Catalog, Apache Polaris, AWS Glue, and others compete to govern open tables. Evaluate catalogue openness, interoperability between Delta and Iceberg, small-file maintenance (compaction), and governance features. Performance tuning such as partitioning and clustering still matters, even with open formats.
Real-world examples
At home
Sophie took an online data engineering course that used a free lakehouse setup. She loaded public transit data as Parquet files, queried it with SQL, and trained a simple delay-prediction model on the same tables.
At work
Thomas is the head of data at a Canadian grocery chain that ran a warehouse for sales reports and a separate data lake for forecasting. Consolidating on a lakehouse removed nightly copy jobs and ended arguments about whose sales numbers were right.
How it compares
| feature | Data lakehouse | Data warehouse | Data lake |
|---|---|---|---|
| Storage cost | Low, open files in object storage | Higher, proprietary storage | Low |
| Reliability | Transactions and schemas | Strong | Weak |
| Workloads | BI, data science, AI | Mostly BI and SQL | Data science and raw storage |
| Vendor lock-in | Lower with open formats | Higher | Low |
The lakehouse aims for warehouse reliability at lake prices.
For analysts
Before a lakehouse migration, I'd ask how many copies of the same data you're paying to store and reconcile today. That number, and the arguments it causes in meetings, is usually the strongest business case.
History & origin
Data warehouses dominated analytics from the 1990s. James Dixon of Pentaho coined 'data lake' in 2010 for cheap storage of raw data, often on Hadoop, but lakes became 'data swamps' without structure or reliability. Netflix created Apache Iceberg, Uber created Apache Hudi, and Databricks released Delta Lake in 2019, each adding database-like tables on top of files. Databricks popularized the term 'lakehouse' in 2020 and published an academic paper on it in 2021. By 2024, Snowflake, Google, AWS, and Microsoft all supported open table formats, and Databricks bought Iceberg's commercial steward, Tabular. In my view, the lakehouse won less because of one product and more because customers refused to keep paying to copy data between systems.