Where you store data determines your cost, query speed, schema flexibility, and what teams can do with it. The three options — warehouse (structured, fast SQL), lake (cheap raw storage of anything), and lakehouse (raw storage with warehouse performance) — are the fundamental storage decision behind every data platform, and the lakehouse is where the modern stack has converged. Interviewers expect you to compare all three and justify a choice.
Why this appears in interviews
Every data-engineering system-design question includes "where does this data live?" The answer drives everything downstream: cost at scale, who can query it, how ML gets training data, and how you handle schema change. A candidate who can lay out the three options with their tradeoffs — and explain why the lakehouse emerged — signals real platform experience.
The mental model — three kinds of libraries
- Warehouse — a curated library: every book catalogued and indexed, fast to find, but only books meeting the standard are admitted and adding one requires a cataloguing process.
- Lake — a storage unit where you throw everything (books, photos, notes, audio): admission is instant and cheap, but finding a specific thing is hard unless you organized it.
- Lakehouse — that same cheap storage unit with a smart catalog that can read anything quickly through a standard query interface.
Data warehouse
- What — a structured store of cleaned, transformed data optimized for SQL, with the schema defined before load (schema-on-write).
- Strengths — fast SQL, strong governance and data quality, dead-simple for analysts and BI, ACID by default.
- Weaknesses — expensive at very large/unstructured scale; rigid schema; weak for raw/semi-structured data and ML feature/blob storage.
- Examples — Snowflake, BigQuery, Redshift.
Data lake
- What — a centralized store of raw data in its original format on cheap object storage (S3, GCS, ADLS), with schema applied at read time (schema-on-read).
- Strengths — very cheap storage, holds anything (JSON, images, logs, Parquet), ideal for ML training data and reprocessing from raw.
- Weaknesses — slow to query without extra engines; weak/absent ACID; easy to turn into a "data swamp" (ungoverned, undiscoverable) without a catalog.
- Examples — S3/GCS + a query engine; historically Hadoop/Hive.
Lakehouse
- What — a metadata + transaction layer on top of a data lake that adds ACID transactions, schema enforcement/evolution, versioning, and fast SQL while keeping object-storage economics.
- How it works — data sits in open columnar formats (Parquet) on object storage; an open table format (Delta Lake, Apache Iceberg, Hudi) adds a transaction log, snapshots, and schema evolution; a query engine (Spark, Trino, Databricks SQL, Snowflake) reads the table metadata for warehouse-like performance.
- Why it emerged — warehouses got too expensive at petabyte scale and couldn't serve ML/unstructured needs; lakes were too hard for analysts and lacked ACID. The lakehouse merges both: one copy of data, both BI and ML on it, cheap storage, ACID tables.
- Examples — Databricks Lakehouse, Iceberg-on-S3 with Trino/Snowflake, Delta Lake.
Naming an open table format (Iceberg/Delta) is the detail that shows you actually understand how a lakehouse gets ACID and schema evolution over plain files — a strong signal.
Schema-on-write vs schema-on-read
The axis underneath the three options:
- Schema-on-write (warehouse) — validate and structure data before it lands. Enforces quality; costs flexibility and up-front modeling.
- Schema-on-read (lake) — land raw, interpret at query time. Maximum flexibility and cheap ingestion; risks inconsistency and swamps.
- The lakehouse gets much of both — cheap, flexible landing plus enforced schemas and evolution on the curated tables.
How to choose
- Fast SQL for analysts + strong governance, mostly structured data → warehouse.
- Cheap storage for huge raw/unstructured data + ML training → lake.
- Both BI and ML on large data, one governed copy → lakehouse (the modern default at scale).
- Small team, budget-conscious, structured needs → start with a managed warehouse (BigQuery/Snowflake); adopt a lakehouse when scale/variety demand it.
Most large orgs land on a lakehouse or a warehouse + lake combination, with the medallion layering (raw → cleaned → business) applied inside it.
Common interview mistakes
Mistake 1: "A data lake is just S3." Without a catalog/table format and governance, it's a data swamp; the table format is what makes it usable.
Mistake 2: Not knowing why lakehouses exist. Warehouses too costly at petabyte scale; lakes too hard for analysts and lacking ACID — the lakehouse resolves both.
Mistake 3: Omitting table formats. Any serious lakehouse answer references Iceberg or Delta Lake and why (ACID, snapshots, schema evolution over Parquet).
Mistake 4: Ignoring cost. Storage-vs-compute economics and scale are usually the deciding factor; say so.
Key vocabulary
- Data warehouse / lake / lakehouse — Structured fast-SQL store / cheap raw store / raw store with warehouse performance.
- Schema-on-write vs schema-on-read — Structure enforced before load vs interpreted at query time.
- Open table format (Delta / Iceberg / Hudi) — Adds ACID, snapshots, and schema evolution to files on object storage.
- Object storage — Cheap, scalable blob storage (S3/GCS/ADLS) underlying lakes and lakehouses.
- Data swamp — An ungoverned, undiscoverable data lake; the failure mode without a catalog.
- Medallion architecture — Raw → cleaned → business layering applied within a lake/lakehouse.