Data Warehouse vs Data Lake vs Lakehouse

A data warehouse stores structured, modelled data in a managed engine built for fast analytical SQL. A data lake stores raw files of any shape in cheap object storage and lets many engines read them. A lakehouse keeps data in open files on object storage but adds a table layer (transactions, schemas, time travel) so the lake can be queried and governed like a warehouse. Most modern platforms use more than one, and the interesting design work is deciding which data lives where.

How the three compare

Schema-on-write vs schema-on-read

A warehouse rejects data that doesn't match its tables at load time, which is schema-on-write. That's friction for producers, but every consumer gets clean, typed columns. A lake accepts anything and pushes interpretation to the reader, which is schema-on-read. That's flexible for exploration and for data whose use isn't known yet, but every reader re-solves parsing, typing and deduplication, often differently.

Lakehouses move the lake towards schema-on-write for curated tables while still allowing raw landing zones. A common split is raw data in open files with minimal rules, and cleaned, conformed tables with enforced schemas and data contracts.

What makes a lakehouse possible

Plain files on object storage have no transactions: a job that writes 500 files can fail after 300, and a reader can see a mix. Open table formats such as Apache Iceberg, Delta Lake and Apache Hudi fix this by tracking which files make up each version of a table in metadata. A commit atomically swaps the table to a new set of files, so readers always see a complete snapshot. The same metadata enables schema evolution, time travel to older versions, and efficient file pruning.

How to choose

• Mostly BI on structured business data, modest scale, a small team: a managed warehouse is the fastest path to trustworthy dashboards.
• Large volumes of raw, semi-structured or unstructured data, plus data science: a lake or lakehouse avoids paying warehouse prices to store everything.
• Many engines and teams on the same data, and a wish to avoid lock-in: a lakehouse with an open table format and a shared catalog.
• Both: land and retain everything in the lake, and serve the hottest curated marts from a warehouse. This is common and perfectly reasonable.

A lake without ownership, documentation and quality checks becomes a data swamp: lots of files nobody trusts. The technology choice matters less than having curated layers with owners, such as the medallion layers.

Costs that decide real designs

• Storage: object storage is far cheaper per terabyte than warehouse storage, which matters for years of raw history.
• Compute: warehouses usually bill per query or per running cluster; lakes pay for whatever engine runs. Scanning fewer bytes (partitioning and columnar formats) cuts both.
• Operations: a lakehouse needs compaction, snapshot expiry and catalog management that a warehouse does for you.
• Egress and duplication: copying the same data into several systems doubles storage and creates consistency problems.