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
Think of a huge self-storage unit where you can dump boxes of anything cheaply, versus a tidy library with a catalogue. The storage unit is cheap but hard to search; the library is organized but costly. A data lakehouse is a storage unit with a librarian: data sits in cheap storage, but a catalogue tracks every item so it can be found and used like a library.
At work
A data lakehouse is a data platform that keeps information in cheap cloud storage, like a data lake, while adding the reliable tables and fast queries of a data warehouse. One copy of data serves both business reports and machine learning, rather than being copied between separate systems. Businesses care because it cuts storage costs, removes copy jobs, and reduces arguments over mismatched numbers.
At home
A lakehouse is built in layers. At the bottom, data sits as files, often in the Parquet format, in cloud storage such as Amazon S3. Above that, a table format such as Delta Lake or Apache Iceberg keeps a log of which files make up each table and how they've changed. A catalogue lists the tables, and query engines like Spark or Trino read them using SQL, as if they were database tables.
At work
At work, a lakehouse provides warehouse features on open storage: ACID transactions so readers never see half-written data, schema enforcement, time travel to earlier versions, and access from many engines, such as Spark, Trino, Snowflake, or Databricks SQL. Data usually flows through layers, often called bronze for raw, silver for cleaned, and gold for business-ready. A shared catalogue such as Unity Catalog or AWS Glue manages permissions and table discovery across engines.
At home
The key design choice is separating storage from compute. Files stay in cheap object storage, and processing engines start up only when needed, then shut down. Because the table format is an open specification, several engines from different vendors can work on the same files. While warehouses are often faster out of the box, in my opinion that separation is what makes switching vendors realistic for the first time in analytics.
At work
Lakehouse architecture has four layers: object storage, an open table format, a catalogue, and query engines. The catalogue has become the new lock-in point, with Unity Catalog, Apache Polaris, AWS Glue, and others competing to govern tables. Weak spots include small-file buildup that requires compaction, concurrent-write conflicts, and imperfect interoperability between Delta Lake and Iceberg. Evaluate catalogue openness, governance features, and maintenance automation, and still plan partitioning or clustering for performance.
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. Uber created Apache Hudi around 2016, Netflix created Apache Iceberg in 2017, and Databricks open-sourced 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.