Data warehouse vs data lake: what's the difference, really?

"Warehouse" and "lake" both store a lot of data, so they're often confused. The real difference is when and how you impose structure — and that single choice ripples through cost, flexibility and who can use the data.

The data warehouse

A data warehouse stores structured, cleaned data modelled for analysis. You decide the schema before loading — "schema-on-write" — so by the time data lands, it's already shaped into tables of facts and dimensions. The ideas trace back to the 1990s work of Bill Inmon and Ralph Kimball. The payoff: fast, reliable SQL and BI dashboards that everyone reads the same way. The cost: getting data in takes upfront modelling, and it suits structured data far more than images, logs or free text.

The data lake

A data lake stores raw data of any type — structured, semi-structured or unstructured — in cheap object storage, as it arrives. You impose structure only when you read it — "schema-on-read". The term was coined around 2010 by James Dixon. Lakes are flexible and inexpensive, and ideal for data science and machine learning that want the raw signal. The risk: without governance a lake becomes a "data swamp" — everything is in there, but nobody can trust or find anything.

Side by side

• Structure: warehouse = schema-on-write; lake = schema-on-read.
• Data: warehouse = structured & curated; lake = raw, any format.
• Users: warehouse = analysts & BI; lake = data scientists & ML.
• Cost: warehouse = higher per TB; lake = cheap object storage.
• Risk: warehouse = rigid; lake = becomes a swamp without governance.

And the lakehouse?

Newer "lakehouse" architectures (popularised by Databricks) try to get both: the cheap, open storage of a lake with the tables, transactions and performance of a warehouse, using formats like Delta Lake, Apache Iceberg or Hudi. For many teams it's a genuine middle path — but it's an architecture to adopt deliberately, not a buzzword to chase.