In this article
Before you start
This page is one part of the data engineer interview guide.
Why interviewers ask this
Where analytical data lives is one of the first choices in a data engineering design, and a weak choice shows up later as stale reports, a duplicated storage bill or tables that break when two jobs write at once. Candidates report this comparison in data engineering and system design rounds at data-focused teams and large tech companies.
The question separates people who recite three definitions from people who can say what each design costs. A weak answer says "a warehouse is structured, a lake is unstructured, a lakehouse is both." A strong answer names when the schema is applied, who is responsible for data quality, what happens when a job fails halfway through a write, and why a company would run two systems at once.
A Staff-level answer adds that a metadata layer alone does not make queries fast, and that much of the public evidence for lakehouse speed comes from vendors. The senior data engineering system design round is where this choice gets applied to a real workload.
What each one is
- Data warehouse
- A data warehouse is a central repository of structured, preprocessed data that serves analytics and business intelligence (BI) queries, with the schema applied when data is written and the whole system tuned for the fastest query performance, so dashboards and analysts get quick, consistent answers.
- Data lake
- A data lake is a low-cost store, usually on cloud object storage, that holds raw data of any kind at any scale in open file formats, with the schema applied only when data is read, which makes it cheap and flexible but leaves data quality and governance to the teams that use it.
- Lakehouse
- A lakehouse is a data management system built on low-cost, directly accessible storage that also provides warehouse-style features such as ACID (atomicity, consistency, isolation, durability) transactions, data versioning, auditing, indexing, caching and query optimization, as defined by Armbrust et al. (2021).
Data warehouse in plain words
A data warehouse is a store where data is cleaned and shaped before it goes in. Think of a supermarket shelf: goods are sorted, labeled and priced before customers see them, so finding milk takes seconds. The analogy breaks in one place. A warehouse owner can still rebuild its tables later, so the shelf is never truly fixed.
Schema-on-write is the practice of checking data and fitting it to a fixed table design before it is stored. Armbrust et al. (2021) say warehouse data was written this way so the data model was optimized for downstream BI use. Amazon Web Services (AWS) describes a warehouse as a central repository of preprocessed data for analytics and business intelligence. The cost is flexibility: data that does not fit the design has no place to go.
Historically the compute and the storage sat together in one on-premises appliance, and commercial warehouses can lock data into proprietary formats, according to the same paper. The data modeling interview questions cover how warehouse tables are designed.
Data lake in plain words
A data lake is a cheap place to drop data first and decide what it means later. Think of a storage unit: you can put anything in any box without labeling it, but finding one item later means opening boxes. The analogy breaks because a lake can have a catalog that records what each box holds.
Schema-on-read is the practice of storing data as it arrives and applying a table design only when a query reads it. A lake can hold structured, semi-structured and unstructured data, and AWS notes that lake architecture prioritizes storage volume and cost over performance. On the cloud a lake commonly sits on object storage such as S3 or Azure Data Lake Storage (ADLS), as Databricks describes; an older home is the Hadoop Distributed File System (HDFS), covered in Apache Hadoop interview questions.
Schema-on-read does not mean governance is optional. Armbrust et al. (2021) write that the lake "punted the problem of data quality and governance downstream."
The transactional metadata layer is what makes a lakehouse
A lakehouse is a lake with a transactional metadata layer; that layer is the defining addition, and caching, statistics and data layout on top of it supply the speed. Plain lake storage gives a low-level file interface where even simple operations, such as updating a table that spans multiple files, are not atomic. A reader can see half of an update.
Take a job that rewrites a table of 8 files and crashes after replacing 5. A reader of a plain lake then sees 5 new files and 3 old ones. With a transaction log the commit never happened, so readers still see the 8 old files.1
In plain words, think of the lake as a floor of boxes and the log as a ledger that lists which boxes make up the current edition of each table; readers trust the ledger, not the floor. The analogy breaks in one place: the ledger does not make any box faster to open.
The fix, in the paper's words, is to "implement a transactional metadata layer on top of the object store that defines which objects are part of a table version." Readers use the files of the latest committed version, so a half-finished write is not part of any version. A table format is software that does this by recording which files make up each table version. Delta Lake extends Parquet data files with a file-based transaction log. Parquet is an open file format that stores a table's data column by column. Apache Iceberg tracks individual data files in a table instead of directories, and it writes new metadata files for each table change.
ACID is a set of four properties of a transaction: it is atomic (all or nothing), consistent, isolated and durable. Iceberg and Delta Lake both create an abstraction layer that allows ACID transactions on data in object storage.
Why many companies ran a lake and a warehouse together
Many companies ran both a lake and a warehouse, called a two-tier architecture, because each covered the other's weakness. Data landed in the lake, and a copy of the cleaned part was loaded into the warehouse by a job that extracts, transforms and loads it (extract, transform, load (ETL); see what a data pipeline is). Armbrust et al. (2021) call this two-tier design dominant in their experience, "used at virtually all Fortune 500 enterprises."
The same paper lists its problems: reliability, because two copies must agree; data staleness; limited support for advanced analytics; and total cost, since "users pay double the storage cost for data copied to a warehouse." It cites a survey by Fivetran that found 86% of analysts used out-of-date data. The lakehouse was proposed to remove the copy. AWS also describes a lake and a warehouse used together, so treat the 2021 statement as dated and the pattern as still common.
How they differ
The three differ in what they hold, how they handle writes and what they optimize for. The sources above give each cell.
| Dimension | Data warehouse | Data lake | Lakehouse |
|---|---|---|---|
| Data held | Structured, preprocessed | Any data at any scale, raw | Any data, organized as tables by a metadata layer |
| Schema | On write | On read | Enforced on write by the table format, with schema evolution |
| Storage format | Often proprietary | Open formats such as Parquet | Open formats such as Parquet |
| Updates | ACID transactions | Not atomic across files | ACID transactions on a table |
| Optimized for | Fastest queries | Volume and cost | Low cost, tuned for SQL speed |
| Typical use | BI and reporting | Exploration, machine learning (ML) | Both, on one copy of the data |
A warehouse loads cleaned data through ETL into its own managed storage and compute. A lake lets engines read raw files on object storage directly. A lakehouse adds a transaction log so engines read only committed versions.
Text description of the diagram
- A warehouse loads cleaned data through ETL into its own managed storage and compute.
- A lake lets engines read raw files on object storage directly.
- A lakehouse adds a transaction log so engines read only committed versions.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
This illustrative example, computed rather than measured, shows what the copy in a two-tier design costs and what a half-finished write does. Assume a lake of 100 terabytes, of which 30 terabytes is curated data that a nightly job also loads into a warehouse.1
The two-tier design stores 130 terabytes, which is 30% more bytes than the lake alone. A lakehouse serves the same curated tables from the files already in the lake, so it stores 100 terabytes.1 Suppose, illustratively, that lake storage costs 1 unit per terabyte-month and warehouse storage costs 2.5 units. The two-tier design then costs 175 units and the lakehouse 100, so the copy raises the storage bill by 75%.1 These are not real prices; the point is that the copy is billed at the dearer rate.
Text description of the diagram
- The two-tier design stores 130 terabytes.
- A lakehouse over the same files stores 100 terabytes.
Now the failure case from the metadata-layer section, in numbers. The job replaced 5 of 8 files before the crash, so in a plain lake 62.5% of the table is updated and the rest is not.1 With a transaction log readers see the 8 old files, a consistent table.
| Quantity | Value (illustrative, computed) |
|---|---|
| Stored data, lake plus warehouse copy | 130 terabytes |
| Stored data, lakehouse | 100 terabytes |
| Storage cost, two-tier | 175 units |
| Storage cost, lakehouse | 100 units |
| Extra storage cost from the copy | 75% |
| Oldest report data, nightly load | 24 hours |
| Average report age, nightly load | 12 hours |
| Average report age, hourly load | 0.5 hours |
| Table seen after a crash, plain lake | 5 new files, 3 old |
| Table seen after a crash, with a log | 8 old files |
The maximum age of report data equals the load interval, because data loaded just before a refresh waits a full interval, and the average age is half of it. A faster load shrinks the gap but does not remove it. Whether you load in batches or as a stream is the subject of streaming vs batch.1
Trade-offs and edge cases
A lakehouse is not automatically faster than a warehouse, because a metadata layer alone is not sufficient to achieve good SQL performance. The paper adds caching, auxiliary data such as min-max statistics (the smallest and largest value of each column per file, so a query can skip files that cannot match), and data layout such as Z-order (sorting data so rows with similar values sit in the same files). Its benchmark claim that Delta Engine, a Databricks query engine, gives comparable or better performance at a lower price comes from the authors' own product, so it is a vendor result, not an independent test.
Transactions have limits. In the 2021 paper, Delta Lake, Iceberg and Hudi, another open table format, "only support transactions on one table at a time," and the Delta log lives on an object store, which the authors say caps transactions per second. Check the current Delta and Databricks documentation before relying on either limit. Format support also differs by platform: Databricks supports only Parquet-based Iceberg tables, per its Iceberg documentation.
The tools around a table format matter as well. Iceberg adds tables to compute engines such as Spark, Trino, Flink and Hive, according to its documentation, so the format is separate from the engine. Reading these tables from Spark is covered in Spark interview questions.
Reported practice differs on whether warehouses will disappear. The lakehouse paper argues they will "wither," but its authors work for a lakehouse vendor, and AWS continues to describe a lake and a warehouse used together.
The line between warehouse and lakehouse is blurring
The lakehouse idea borrows from the warehouse: Armbrust et al. (2021) note that the trend in lake systems has been to add ACID support, and their definition lists indexing, caching and query optimization, which warehouses already had. The format is also separate from the engine, since Iceberg adds tables to compute engines such as Spark, Trino and Flink. So the choice is less binary than three definitions suggest. In an interview, say that the designs are converging, then say what you would check: which table format and engine are in use, and who owns data quality.
How to choose
Choose a warehouse when the work is mostly reports on structured data. Choose a lake when you need raw data and can live without transactions. Choose a lakehouse when you need raw data, transactions and fast SQL.
Text description of the diagram
- Choose a warehouse when the work is mostly reports on structured data.
- Choose a lake when you need raw data and can live without transactions.
- Choose a lakehouse when you need raw data, transactions and fast SQL.
Ask the two questions in the order shown. The first separates a warehouse, which wants structured data fitted to a design on write, from the two designs that keep raw files. The second separates a plain lake, where a failed write can leave a half-updated table, from a lakehouse, where a transaction log keeps readers on committed versions. If both answers are yes and you already run a warehouse, the saving is the copy, but moving has its own cost, so the decision depends on your data volume, your tools and who owns data quality.
How to answer it in an interview
What is the difference between a data warehouse, a data lake and a lakehouse?
A warehouse stores structured, cleaned data with the schema applied on write, and it is tuned for fast BI queries. A lake stores raw data cheaply on object storage with the schema applied on read, but plain files give no atomic multi-file updates. A lakehouse keeps the lake's storage and adds a transactional metadata layer, such as Delta Lake or Iceberg, so you get ACID transactions on the same files. I would pick a warehouse for reporting, a lake for raw and machine learning data, and a lakehouse when I want both without copying data twice. The trade-off is that the metadata layer does not give warehouse speed; you still need caching, statistics and data layout.
The spoken structure: define each in one clause, name the metadata layer as the difference, then give the trade-off and when you would pick each.
Common mistakes
- "A lakehouse is just a data lake with a new name." (wrong) The defining feature is the transactional metadata layer. (right) "A lakehouse is a lake plus a metadata layer that adds ACID transactions and versioning."
- "A lake holds only unstructured data." (wrong) It holds structured, semi-structured and unstructured data. (right) "A lake holds data of any kind, raw, with the schema applied on read."
- "Schema-on-read means no governance is needed." (wrong) Quality and governance are pushed downstream, not removed. (right) "Someone must own quality when the schema is applied on read."
- "Delta Lake is a database or a query engine." (wrong) It is a storage layer over Parquet files with a transaction log. (right) "Delta Lake and Iceberg are table formats; an engine such as Spark queries them."
- "A lakehouse is faster than a warehouse everywhere." (wrong) The speed claims are largely vendor results and need tuning. (right) "A metadata layer adds management, and speed still needs caching and layout."
Follow-up questions
What is the difference between a data lake and a data warehouse?
A warehouse stores structured, preprocessed data with the schema applied on write and is built for the fastest queries. A lake stores raw data of any kind with the schema applied on read and prioritizes volume and cost over performance.
Is a lakehouse just a data lake with a new name?
No. A lakehouse keeps the lake's low-cost storage and adds a transactional metadata layer that provides ACID transactions, versioning and indexing, which plain file storage lacks.
Is Delta Lake a database?
No. Delta Lake is open source software that extends Parquet files with a transaction log, so it is a storage layer that engines such as Spark query. See PySpark tutorial for working with such tables.
Can a lakehouse replace a data warehouse?
Sometimes, but not everywhere. It removes the copy and the second storage bill, yet its speed needs tuning and its transactions were single-table as of 2021. How to weigh this choice inside a full design is covered in the senior data engineering system design round.
What is schema-on-read versus schema-on-write?
Schema-on-write fits data to a table design before storing it, which gives clean tables and rejects misfits. Schema-on-read stores data first and applies the design when a query reads it, which is flexible but moves quality checks downstream.
- A warehouse holds cleaned, structured data for the fastest queries; a lake holds raw data of any kind cheaply.
- A lakehouse is a lake plus a transactional metadata layer that adds ACID transactions and versioning.
- A plain lake cannot update many files atomically; a table format makes a write all or nothing.
- The metadata layer alone does not give warehouse speed, and most lakehouse benchmarks are vendor results.
- Pick by two questions: do you need raw data, and do you need transactions?
Sources
- Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics (CIDR 2021) — CIDR (Armbrust, Ghodsi, Xin, Zaharia), 11 Jan 2021
- What is Delta Lake in Databricks? — Databricks documentation, 26 Oct 2026
- What is Apache Iceberg in Databricks? — Databricks documentation, 26 Oct 2026
- Apache Iceberg table spec — Apache Software Foundation, 26 Oct 2026
- Apache Iceberg documentation — Apache Software Foundation, 26 Oct 2026
- Data Lake vs Data Warehouse vs Data Mart — Amazon Web Services, 26 Oct 2026
- Data Lakes vs Data Warehouses — Databricks blog, 26 Oct 2026
