Data Warehouse, Data Lake or Lakehouse: An Architectural Comparison
The three patterns now share more technology than their names suggest. What still separates them is where structure is imposed, who can read the stored data, and what the organisation is equipped to run.
A data warehouse stores data that has been structured before it is loaded, for fast and consistent reporting. A data lake stores data in its original form at low cost and leaves structure until the data is used. A lakehouse keeps the lake’s open, low-cost storage and adds a layer that gives it the transactional and management features of a warehouse.
Those three sentences are accurate and are no longer enough to choose between them. Warehouses now query files they did not load. Lakes have acquired transactions. The comparison a buyer needs is by criterion, and the criteria that still matter are workload fit, consistency and governance, cost behaviour, skills and lock-in. This article takes them in turn. It assumes the vocabulary set out in modern data architecture: the layers, patterns and decisions that matter.
One caution applies to everything that follows. A comparison published by the vendor of one of the options is an argument for that option. The sources used here include vendor-affiliated papers too, and each is identified as such where it is cited.
Three patterns, briefly
The warehouse imposes structure on the way in. Microsoft’s architecture guidance summarises the type of data it holds as “Structured and curated data organized into relational schemas”1. The benefit is that every reader gets the same, already-shaped tables. The cost is the work of shaping before anything can be queried.
The lake defers that work. The same guidance defines it as “a storage repository that holds large volumes of data in its native, raw format” and lists what follows when the deferred work is never done: “Without proper cataloging, lakes can devolve into data swamps where valuable information is present but inaccessible or misunderstood”1.
The lakehouse was named in a 2021 paper whose authors are affiliated with Databricks, a company that sells one. They argued that running a lake and a warehouse together had become the norm and was costly: “Keeping the data lake and warehouse consistent is difficult and costly”2. Their proposal was to add warehouse features directly to lake storage, which they list as “ACID transactions, data versioning, auditing, indexing, caching, and query optimization”2. The paper is an argument for a product direction as well as a description of a pattern, and should be read with that in mind.
Where the lines have blurred
The technology that made the lakehouse possible is the open table format: a layer of metadata that turns a collection of files in cheap object storage into something that behaves like a database table.
The problem it solves is specific. Object stores were not built for tables. The paper introducing Delta Lake, also from Databricks, explains that with such stores “metadata operations such as listing objects are expensive, and consistency guarantees are limited”3. Its answer is “an open source ACID table storage layer over cloud object stores” that provides “ACID properties, time travel, and significantly faster metadata operations”3.
Delta Lake is one of three open formats discussed here. The Apache Iceberg project describes itself in similar terms, as “an open table format for huge analytic datasets”, and states its guarantee plainly: “table changes are atomic and readers never see partial or uncommitted changes”4. Apache Hudi’s documentation lists what it brings to a lake as “tables, transactions, efficient upserts/deletes, advanced indexes, ingestion services, data clustering/compaction optimizations, and concurrency control”5.
Two consequences follow for anyone comparing patterns.
The first is that transactions are no longer a reason, in themselves, to choose a warehouse. A lake with a table format can offer atomic changes and consistent reads.
The second is that the boundary between a warehouse and a lake has become a matter of which engine is reading. The Delta Lake paper notes that its tables “can be accessed from Apache Spark, Hive, Presto, Redshift and other systems”3, and Redshift is a warehouse product. Iceberg’s documentation names “Spark, Trino, PrestoDB, Flink, Hive and Impala” as engines that can use its tables4. When several engines, including warehouse engines, read the same stored tables, the question of which pattern an organisation has is less useful than the question of where its data lives and who controls the format.
Five criteria that still separate them
The three patterns compared on five criteria
| Criterion | Warehouse | Lake | Lakehouse |
|---|---|---|---|
| Workload fit | Reporting and SQL analysis on structured data | Data science, machine learning and storage of varied raw data | Both, from one copy of the data, with more to configure |
| Consistency and governance | Enforced by one engine that owns the data | Left to convention unless a table format and catalogue are added | Supplied by the table format and catalogue; enforcement must cover every engine |
| Cost behaviour | Predictable for steady reporting; rises with stored volume and concurrency | Low storage cost; compute paid when data is processed | Low storage cost; one copy; compute cost depends on engines chosen |
| Skills required | SQL and data modelling | Distributed processing and file-format knowledge | Both, plus operation of the table format |
| Lock-in | Data held in the vendor’s format | Open file formats; logic tied to the processing framework | Open table format; lock-in moves to the catalogue and to engine-specific features |
The table is DII’s synthesis. The sections below say which parts rest on the sources and which are judgement.
Workload fit
This is the criterion with the clearest evidence. The lakehouse paper’s central complaint about warehouses is that machine learning systems “need to process large datasets using complex non-SQL code”, which a SQL interface serves poorly2. Microsoft’s guidance makes the complementary recommendation for lakes: “exploratory analytics, advanced data science, and machine learning workloads”1.
For an organisation whose analytical work is reporting on well-understood business data, a warehouse fits and the other two add components it will not use. For one whose work is mostly model training on varied or unstructured data, a warehouse alone does not fit. The lakehouse case is strongest where both kinds of work are substantial and draw on the same data.
Consistency and governance
A warehouse enforces its rules in one place because one engine owns the data. That simplicity is easy to undervalue.
In a lakehouse the guarantees come from the table format, and they are real: Iceberg’s documentation says it “was designed to solve correctness problems in eventually-consistent cloud object stores”4. But the lakehouse paper is candid about what direct access to files costs. Lakehouses, its authors write, “give up some aspects of data independence, which has been a cornerstone of relational DBMS design”2. In practical terms, when several engines can read the files, an access rule or a masking policy has to be enforced for all of them, which is the job of a shared catalogue. Whether that enforcement is complete is a question to put to any lakehouse design. The governance side of this is covered in data mesh vs data fabric, where the unit being governed is the data product.
Cost behaviour
The sources agree on the direction and offer no neutral figures. Microsoft’s comparison gives the lake “Lower storage cost because of low-cost storage for raw data” and the warehouse “Higher cost because of dedicated compute and performance optimizations for analytical workloads”1. The lakehouse paper’s argument is about duplication: with two systems, “users pay double the storage cost for data copied to a warehouse”2.
What neither settles is total cost for a particular workload. Compute cost depends on query patterns, concurrency and how well the engine is tuned, and none of those can be read from a storage price. DII’s advice is to treat any published cost comparison as a claim about one vendor’s benchmark, and to test with the organisation’s own queries before relying on it.
Skills
This criterion is DII’s judgement and has no direct source. A warehouse can be run by a team whose skills are SQL and data modelling. A lake needs people comfortable with distributed processing frameworks and file layouts. A lakehouse needs both, and someone who understands how the table format compacts files, expires snapshots and handles concurrent writers. An organisation that cannot staff the third list will not get the benefits the pattern promises, whatever the product documentation says.
Lock-in
The lakehouse paper states the case against the warehouse directly: “commercial warehouses lock data into proprietary formats that increase the cost of migrating data or workloads to other systems”2. Open table formats do reduce that particular dependency. The data stays in files the organisation controls, in a format with a public specification; Iceberg’s is published as a specification “designed to manage a large, slow-changing collection of files in a distributed file system or key-value store as a table”4.
Lock-in does not disappear. It moves. The catalogue that tracks tables, the engine-specific performance features and the surrounding security model can each become the thing that is hard to leave. A comparison that claims a pattern has no lock-in has stopped looking one layer too early.
Capability claims have a short shelf life
One detail in the sources is a useful warning. The 2021 lakehouse paper says of Apache Hudi that “it does not support concurrent writers”2. Hudi’s current documentation lists “concurrency control” among its core functions5. Both statements were made in good faith about the software as it stood.
The point for a buyer is that feature-by-feature comparisons of these formats and engines can go out of date between one release and the next. A decision that rests on one project lacking a feature should be checked against that project’s current documentation on the day the decision is made, and the check recorded.
Choosing, by situation
No source prescribes a choice, and the following is DII’s guidance.
- Reporting on structured business data, with a SQL-skilled team. A warehouse. Adding a lake brings components and skills the work does not need.
- Heavy data science or machine learning on varied data, little formal reporting. A lake with a table format. A warehouse can be added later for the reporting that emerges.
- Substantial reporting and substantial data science on the same data. A lakehouse is worth its extra operational demands, provided the team can meet them.
- A warehouse and a lake already in place, kept in step by pipelines. This is the two-system arrangement the lakehouse paper criticises. Consolidation may pay, but the migration is a project with its own risks, and the existing arrangement is not wrong merely because a newer pattern exists.
How data moves between stages in any of these, and whether it is transformed before or after loading, is a related decision treated in ETL vs ELT: how to choose for your workloads. Choosing the product once the pattern is settled is the subject of how to evaluate and select a data platform.
Whatever is chosen, the reasoning should outlive the meeting in which it was agreed. Architecture decision records for data teams describes how to record the options considered and the consequences accepted. The Data Architecture Decision Framework gives that record a structure, and the Data Architecture Assessment helps establish the starting position the decision is made from.
Sources
- Microsoft. What is a data lake? (Azure Architecture Center, Microsoft Learn). Updated 21 April 2026.
- Armbrust, M., Ghodsi, A., Xin, R. and Zaharia, M. Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. 11th Conference on Innovative Data Systems Research (CIDR 2021). January 2021.
- Armbrust, M. et al. Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores. Proceedings of the VLDB Endowment, 13(12), 3411-3424. 2020.
- Apache Software Foundation. Apache Iceberg documentation (introduction) and Iceberg Table Spec.
- Apache Software Foundation. Apache Hudi: Overview (documentation, version 1.2.1).
This article is general professional information. It is not legal or regulatory advice.