A data lakehouse puts the reliability and performance features of a data warehouse - ACID transactions, schema enforcement, time travel, fast SQL - directly on top of cheap, open data-lake storage. The point is to stop maintaining two systems. Instead of landing raw data in a lake and then copying a curated subset into a separate warehouse, the lakehouse runs both exploratory and production analytics over the same open files.
What makes it work: the table format
A raw data lake is just files in object storage with no notion of a transaction - a job that writes 500 Parquet files and crashes at file 347 leaves a half-written, unreadable table. The lakehouse adds a metadata layer that turns those files into a real table. Delta Lake, Apache Iceberg, and Apache Hudi each track which files belong to which version of the table, enforce schema on write, and expose snapshot isolation so readers never see a partial commit. The data is still Parquet underneath; the table format is the "table of contents and version history" laid over it.
One copy, many engines
Because the data and its metadata are open formats, multiple engines query the same tables without copying: Spark for ETL and ML, a SQL warehouse engine for BI, Trino or DuckDB for ad hoc queries. This is the practical payoff over the warehouse-plus-lake split - no nightly export job, no two copies drifting out of sync, no vendor lock on the storage layer. Governance and access control apply once, at the table, rather than separately per system.
Where it fits and where it doesn't
The lakehouse shines when you have large, varied data and want SQL analytics, data science, and ML over one store - it's the natural home for the medallion architecture. It's weaker where a tuned warehouse still wins: very high-concurrency BI with strict sub-second SLAs, or heavy small-update transactional workloads, where a purpose-built warehouse or OLTP engine fits better. Many organizations run a lakehouse for the bulk of data and keep a specialized engine for the hottest serving layer.
Frequently asked questions
How is a lakehouse different from a data lake? A data lake is raw files with no transactions or schema guarantees; a lakehouse adds a table format (Delta, Iceberg, Hudi) that provides ACID transactions, schema enforcement, and time travel over those same files.
Does the lakehouse replace the warehouse? Often it replaces the lake-plus-warehouse pair for analytics, but a dedicated warehouse engine can still serve high-concurrency, low-latency BI better. The two coexist in many stacks.
Which table format should I use? Iceberg has the broadest engine support, Delta Lake is the default on Databricks, and Hudi is strong for incremental/CDC ingestion. All three now offer ACID, schema evolution, and time travel.
Is the data still open? Yes - the files are open Parquet and the metadata formats are open specs, so the lakehouse avoids locking your data into one vendor's storage.