Data Warehouse vs Data Lake
A warehouse stores structured, schema-on-write data for analytics; a lake stores raw, schema-on-read data of any type. Each fits a different need.
Two storage philosophies
A data warehouse and a data lake both hold large volumes of data for analysis, but they embody opposite philosophies about when structure is imposed. The warehouse structures data on the way in; the lake stores it raw and structures it on the way out. Understanding the trade-off explains why organizations often run both.
Schema-on-write versus schema-on-read
A warehouse uses schema-on-write: data must conform to a defined schema before it is loaded, so everything inside is clean, typed, and immediately queryable. A lake uses schema-on-read: raw data of any format is stored as-is, and structure is applied only when something reads it. Schema-on-write front-loads discipline and guarantees quality; schema-on-read front-loads flexibility and defers commitment.
Trade-offs compared
| axis | warehouse | lake |
|---|---|---|
| structure | on write | on read |
| data types | tabular | any |
| quality | enforced | varies |
| flexibility | lower | higher |
Strengths and failure modes
- Warehouse: fast, reliable analytics on curated data; rigid and narrow in type
- Lake: cheap, flexible storage for raw and unstructured data of every kind
- Lake failure mode: a "data swamp" of undocumented, ungoverned files nobody trusts
- Warehouse failure mode: everything useful must be modeled before it can be stored
Why organizations run both
A common pattern lands raw data in a lake, keeps it as the complete replayable record, and then loads cleaned, modeled subsets into a warehouse for reliable analytics. The lake gives flexibility and full history; the warehouse gives quality and speed. The tension between them, flexibility versus governance, motivated a third design that tries to combine their strengths on one storage layer. See the lakehouse, OLAP vs OLTP, and the medallion architecture.