How the three patterns differ by decision
| Dimension | Data warehouse | Data lake | Lakehouse |
|---|---|---|---|
| Best-fit workload | Governed concurrent reporting and analytics on modelled data. | Retention of raw and semi-structured data, exploratory processing and archives. | One copy serving processing, analytics and machine learning. |
| Architecture | Modelled schemas on a query-optimised store with separated compute. | Files in object storage with a processing engine reading them directly. | Object storage plus open table formats, a catalogue and transactional guarantees. |
| Governance | Access, masking and lineage provided by the platform. | Assembled by you: permissions, catalogue, classification and retention. | Catalogue-led, with access enforced at table and file level. |
| Performance model | Optimised for concurrent SQL at predictable latency. | Depends on file layout, partitioning and the query engine. | Tunable, but compaction and file layout become ongoing work. |
| Skills required | SQL and data modelling. | File formats, partitioning and processing engines. | Both: modelling discipline plus pipeline and layout engineering. |
| Cost model | Compute and storage tracked separately, driven by concurrency. | Cheap storage, cost shifts to compute and maintenance effort. | Storage, compute and engineering effort spread across the stack. |
| Limitations | Weak at raw semi-structured data and heavy distributed processing. | Governance and query performance require work you must sustain. | More moving parts to operate than either pattern alone. |
| Migration implications | Moving in means adding modelling and reconciliation, not just copying tables. | Moving out means rebuilding pipelines, layout and access. | Migrating into it re-platforms storage and rewriting jobs at the same time. |
Define the three patterns before comparing them
A warehouse is a modelled, query-optimised store with schemas, keys and access built for reporting. A lake is cheap object storage holding raw and processed files with little imposed structure. A lakehouse adds an open table format, a catalogue and governance on top of lake storage so the same files can be queried like tables and read by engines that need them, usually arranged with the medallion layering.
The lakehouse depends on an open table format, typically Delta Lake, Apache Iceberg or Apache Hudi, which keeps a transaction log beside the data files. The log is what allows concurrent writers, consistent reads, schema evolution and querying a table as of an earlier version. Plain files in a bucket provide none of those.
- Warehouse: modelled, governed, fast for concurrent SQL
- Lake: cheap, flexible, weak on governance and performance without extra work
- Lakehouse: lake storage with transactional tables, catalogue and access control
Decide from the consumer list
Which people and systems read the data, how many at once, and what do they need: a governed measure, a raw record, or a feature set for a model? A reporting estate with strong metric definitions is a warehouse problem. A platform feeding models, streaming and exploratory work from the same raw files is a lakehouse problem. Copying everything into both is the choice that quietly costs the most.
Where governance actually lives
Governance is not a property of the storage pattern; it is what you build on top. Warehouses ship access models, masking and lineage as part of the platform. Lakes require you to assemble permissions, catalogues and classification yourself. Lakehouses sit between the two, and the catalogue becomes the place where access and lineage have to be coherent.
- Identity, access and masking defined once and enforced at the storage layer
- Lineage generated by the pipeline, not drawn by hand
- Retention and deletion rules that reach derived files and indexes
Cost is the whole path, not the storage bill
Object storage looks inexpensive per terabyte and becomes expensive through query compute, repeated transformations, small files and the engineering time spent on layout. Warehouses concentrate cost in compute and concurrency. Lakehouses spread cost across storage, processing and maintenance. Compare total cost of ownership for the workload, including the people who keep it efficient.
Small files are the most common hidden cost in a lake. Thousands of tiny files from a streaming job make every query open more objects and read more metadata. Periodic compaction to a target file size is routine maintenance, and it needs an owner.
Migration implications
Moving between patterns is a workload change, not a copy exercise. Consumers, schedules, permissions and reconciliation travel with the data, and equivalence has to be proven on business measures rather than row counts. Migrating a lake to a warehouse usually means adding modelling discipline; migrating a warehouse to a lakehouse usually means rebuilding pipelines and file layout.
Illustrative example · hypothetical organisation
Worked example: where each dataset belongs
Consider a hypothetical manufacturer with three kinds of data: ERP orders, machine sensor readings and scanned quality certificates.
Orders are structured, change slowly and feed finance reporting, so they belong in a governed warehouse model with a stated grain. Sensor readings arrive at high volume and are mostly read by engineers building anomaly models, which suits lake storage with a table format. The certificates are documents: keep them in object storage with metadata and an owner, and do not force them into tables.
The boundary is one curated layer. Daily machine-utilisation measures derived from the sensor data are modelled once and published to reporting beside the orders, so finance and engineering read the same number without the raw readings being copied into the warehouse.
The pattern that usually works
Most practical estates land on one governed definition layer that reporting reads, frequently arranged as medallion layers, lake storage that retains raw and semi-structured data, and an explicit boundary between them. The boundary is the design decision: it decides where cost lands, who owns quality, and how many copies of the same fact exist.
Questions and trade-offs
Question
Do we need a lake if we already have a warehouse?
Only if something genuinely needs files rather than modelled tables: raw retention, semi-structured data, model training or archiving at volume. Keep the lake and the warehouse deliberate, with one definition layer, instead of duplicating every dataset into both.
Question
Does a lakehouse replace the warehouse?
It can, when the same team owns processing, analytics and machine learning and the workloads justify one platform. For a reporting estate with strong metric definitions and modest processing needs, a warehouse is usually simpler and cheaper to operate. Decide from the consumers, not the label.
Question
What is an open table format?
A specification that stores a transaction log and metadata next to data files in object storage, so engines can read and write those files as tables with consistent snapshots, schema evolution and time travel. Delta Lake, Apache Iceberg and Apache Hudi are the common ones. The format matters because it decides which engines can read your data without copying it.
