A cost-versus-governance curve

These three are not interchangeable buzzwords; they sit at different points on a cost-versus-governance curve, and picking wrong gives you either an expensive warehouse full of data you cannot afford to keep or a cheap lake nobody can query.

Data warehouse

Snowflake, BigQuery, Redshift. Schema-on-write: data is validated, typed, and modeled into curated tables before it lands. You get strong BI performance, first-class SQL, fine-grained governance, ACID, and reliable joins. The cost is rigidity and price: warehouses are optimized for structured/tabular data, ingesting raw JSON, logs, images, or video is awkward and expensive per TB, and schema changes are work. Great when the workload is dashboards and known reports over clean tabular data.

Data lake

Files on S3/GCS/ADLS, usually Parquet/ORC/JSON. Schema-on-read: dump raw data cheaply now, impose structure at query time. Object storage is roughly 10x to 50x cheaper per TB than warehouse storage and holds any format, which is why ML and log workloads live here. The failure mode is the data swamp: with no catalog, no schema enforcement, and no ownership, the lake fills with undocumented files nobody trusts or can find, and every query becomes archaeology. A lake without governance is where data goes to die.

Lakehouse

Databricks, or a warehouse engine reading open tables on S3. The synthesis: lake economics (cheap object storage, open formats, any data) plus warehouse features (ACID transactions, schema enforcement and evolution, time travel, governance) delivered through an open table format (Iceberg, Delta Lake, Hudi) layered over the raw Parquet files. You keep one cheap copy of the data and get warehouse-grade reliability on it. That is the pitch, and it is why the industry converged here for combined BI plus ML.

The medallion pattern

  bronze  raw, append-only, exactly as ingested (audit + replay source)
  silver  cleaned, deduped, conformed, joined; schema enforced
  gold    business-level aggregates / marts, serving BI and ML features

Each layer has an owner and a contract; downstream consumers read gold, data engineers own the promotion between layers. This is governance you can actually enforce.

Separation of storage and compute

The enabler underneath all of this. In old Redshift/on-prem warehouses, storage and compute were coupled on the same nodes, so to store more you paid for more compute and vice versa, and one workload starved another. In the lake/lakehouse (and modern Snowflake/BigQuery) storage is object storage and compute is separate, elastic clusters. That means you scale them independently (cheap to store 50TB, spin up compute only when querying), run multiple engines on one copy (Spark for ML, Trino for interactive SQL, Flink for streaming, all reading the same Iceberg tables), and give each team its own compute so they do not contend.

Interview nuance: "lakehouse" without a catalog and table format is just a lake with good intentions. The ACID, schema evolution, and time travel come specifically from the table format plus a catalog, not from putting Parquet on S3. If someone says "lakehouse" ask what table format and catalog, that is where the substance is.

Recap: warehouse is schema-on-write, curated, strong BI/governance, pricey for raw data; lake is schema-on-read, cheap object storage, risks becoming a swamp; lakehouse gets lake economics plus warehouse features via open table formats and a catalog; use the medallion (bronze/silver/gold) pattern for governed refinement; separating storage and compute lets you scale independently and run many engines on one copy.

Warehouse vs Lake vs Lakehouse