Data Lakes
Beginner 12 min read Data Lakes

Lake vs Warehouse, Revisited

Not a fork — a spectrum

The lake/warehouse boundary dissolved into a spectrum: raw fidelity + open formats + commodity storage on the lake side; managed modeling, governance, and BI-grade SQL on the warehouse side. The lakehouse sits in the middle.

lake vs warehousespectrumopen formatsmanagedlakehouseconvergence
Prerequisites: Lakehouse Warehouse Architecture
Before we start

What you will learn

  • Restate the practical differences that remain after the lakehouse
  • Choose a landing zone based on freshness/governance needs
  • Design for both without duplicating data
Introduction

What is this?

The old lake-vs-warehouse binary became a spectrum: store raw everything and pay per scan (lake), or model/curate and get managed SQL (warehouse). The lakehouse merges them — open files with transaction logs and SQL engines. Remaining differentiators are governance rigidity, caching, and who runs the SQL.

Motivation

Why do you need it?

  • Architecture decisions still hinge on this spectrum: where do events land, where do dashboards read, who owns the copy?
  • Avoiding the word 'copy' in meetings prevents most data-platform drift.
  • The lakehouse only helps if your tooling consistently reads your lake's files.
Think about it

Mental model

Imagine

A farmers market (raw) vs a packaged-goods store (curated)

Think of

Lake vs warehouse

The market is cheap, unpreserved, and you sort what you buy; the store is processed, labeled, and convenient but costs more per unit and drops exotic ingredients. A co-op deli (lakehouse) refines market goods into labeled packs without the store markup.

Mechanics

How it works

  • Lake traits: commodity storage, open formats, schema-on-read, per-scan economics, full fidelity.
  • Warehouse traits: modeled star schemas, governance/access, caching, managed concurrency, BI-grade SQL.
  • Lakehouse traits: transaction logs, snapshot reads, SQL engines, governed catalogs over open files.
  • The spectrum means 'raw' and 'curated' become zones of one platform, not two systems.
  • Practical choice: trust an SLA; pick where freshness and governance must bind, and keep rawness where discovery needs it.

One platform, several zones on the spectrum.

Raw files
Table format
Curated marts
Governance
BI / ML
Hands-on

Examples

The one-copy architecture

The one-copy architecture
# Input events:
s3://platform-lake/raw/events/*.json          # lake: schema-on-read, keep everything
# Table-format zone:
s3://platform-lake/iceberg/events/           # lakehouse: transactional tables
# Curated marts:
iceberg: cur_sales, dim_customer             # warehouse behavior, same files
 
# Dashboards/ML read the table-format/curated layers;
# discovery can still hit raw JSON via DuckDB/Trino.

Every zone is one storage platform; governance and SQL apply at the layers consumers use.

Real world

In production

  • A data platform keeps raw dumps for regulatory fidelity while exposing BI through lakehouse tables.
  • A warehouse team adds a raw-landing zone to avoid the 'copy into the warehouse or nowhere' trap.
  • A startup builds on one lake + DuckDB/Trino, deferring a managed warehouse until SLAs demand it.
Guidelines

Best practices

  • Design zones with an explicit consumer: raw for discovery, modeled for dashboards/ML.
  • Keep one canonical storage so 'lake vs warehouse' is layers, not siloes.
  • Map each consumer to a freshness/governance model before choosing a zone.
  • Monitor that dashboards read the modeled zone, not raw files by accident.
Watch out

Common mistakes

  • Forcing everything raw into one zone and asking BI to interpret the mess.
  • Duplicating the same data into lake + warehouse 'just in case', paying twice for storage and drift.
  • Expecting the lakehouse to remove governance: it standardizes it, it does not automate the thinking.
When things break

Debugging tips

  • When dashboards read raw flies and are slow, move them to the modeled/table-format layer.
  • When warehouse numbers differ from lake data, pick a canonical table-format zone and re-point consumers.
  • A 'healthy' platform review checks zone → consumer mapping rather than the total petabyte count.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

The modern decision is usually not lake OR warehouse, but which zones of one platform each workload reads.

2

Which trait is more 'warehouse' than 'lake'?

Go deeper

Official documentation

Databricks lakehouse architecture
docs
Iceberg multi-engine docs
docs