🧱 Foundations · Chapter 7

Data lake vs warehouse vs lakehouse

A warehouse is a restaurant: fast, clean, expensive, you eat what's on the menu. A lake is a wholesale market: cheap, anything goes, bring your own knives. The lakehouse is the attempt to get restaurant service at market prices.

Study this lesson free in the app →

The basics

A data warehouse is a database built for analytics: you load cleaned, typed tables into it and query them with SQL (Snowflake, BigQuery, Redshift). A data lake is cheap object storage (S3, GCS, ADLS) holding files in any format, which many engines can read. A lakehouse puts an open table format (Delta Lake, Apache Iceberg, Apache Hudi) on top of the lake so those files behave like warehouse tables — transactions, updates, schema enforcement.

The problem it solves: companies need two things that used to conflict — cheap storage for everything (raw events, logs, images, ML data) and reliable, fast SQL tables for reporting. For years that meant keeping data twice: in the lake and copied into the warehouse.

The mental model: separate where bytes live from who manages them.

• Warehouse: the vendor manages storage, format and compute together
• Lake: you own the files; nothing manages them
• Lakehouse: you own the files; a table format's metadata manages them

Explained

Meghalaya Cabs stores 40 TB of GPS pings, ride events and support-call audio. Putting all of it in Snowflake would cost a fortune. Putting all of it in S3 means the finance team can't run a reliable UPDATE when a refund lands.

Where data lives and how it's managed used to be one decision. The lakehouse made it two.

The godown and the showroom

A furniture business has a godown on the edge of town: cheap rent, huge, everything goes in — raw timber, half-built chairs, returns. Finding a specific chair takes a man with a torch and an hour. That's the lake.

It also has a showroom in Police Bazar: expensive per square foot, only finished, labelled pieces, and a customer finds what they want in a minute. That's the warehouse.

For years every chair was built in the godown and then trucked to the showroom. The lakehouse idea: put shelving, labels and a stock register inside the godown, so customers can shop there directly — and stop paying for the truck.

Side by side

                 WAREHOUSE        LAKE              LAKEHOUSE
─────────────────────────────────────────────────────────────────
storage          vendor-managed   object storage    object storage
format           proprietary*     any files         Parquet + table
                                                    format metadata
schema           on write         on read           enforced on write
ACID / UPDATE    yes              no                yes
time travel      yes (limited)    no                yes (snapshots)
engines          the vendor's     any               many (Spark, Trino,
                                                    Flink, warehouses)
unstructured     poor             yes               yes (alongside)
cost / TB        high             lowest            low
ops effort       low              high              medium

• Snowflake, BigQuery and Redshift can now also read/write Iceberg tables — the lines are blurring.

Before and after the lakehouse

The two-tier design keeps two copies, two permission systems and a sync job that can drift. The lakehouse keeps one copy on open formats that many engines read.

Medallion layers at Meghalaya Cabs

 BRONZE (raw, append-only)           as it arrived
  s3://mc-lake/bronze/ride_events/   JSON from Kafka, never edited
        │  parse, dedupe, type, conform
        ▼
 SILVER (clean, conformed)          one row per real thing
  silver.rides, silver.drivers       Delta/Iceberg, MERGE-able
        │  join, aggregate, apply business rules
        ▼
 GOLD (business-ready)              what dashboards read
  gold.daily_city_revenue            ₹ by city by day
  gold.driver_payouts

Bronze is your insurance policy: if silver logic was wrong, rebuild from bronze.

The GDPR-style deletion request

A rider asks Meghalaya Cabs to delete their data (India's DPDP Act gives them that right).

Plain lake: their rides are scattered across 9,000 Parquet files. You must find every file containing them, rewrite each without those rows, and swap files while queries are running — readers may see half-rewritten data. Usually a weekend project.

Warehouse: DELETE FROM rides WHERE rider_id = 'r_8812'. Done.

Lakehouse: the same DELETE statement. The table format rewrites the affected files (or writes delete files), then commits a new snapshot atomically — readers see before or after, never in between. (Old snapshots still hold the rows until you expire/vacuum them — part of the job.)

At scale: choosing honestly

Pick a warehouse first if you're a small team doing mostly SQL analytics on structured data. Snowflake/BigQuery need near-zero ops and the bill at small scale is less than one engineer.

Move toward a lakehouse when: data is huge (hundreds of TB+), much of it is semi-/unstructured, ML teams need raw files in Python/Spark, or several engines must share one copy without vendor lock-in.

What most companies actually run: a lake for raw/bronze plus either a warehouse or lakehouse tables for silver/gold. With Iceberg support in Snowflake and BigQuery, "lakehouse vs warehouse" is increasingly which engine queries the same open tables.

Senior point: the costs move. A lakehouse lowers storage and licence bills but you now own compaction, snapshot expiry, catalog and access control.

Gotchas

• "Data lake" as a plan. Dumping files without a catalog, ownership or layout becomes a data swamp nobody trusts
• Thinking schema-on-read means no schema. It means every reader re-implements the schema — and they disagree
• Saying a lakehouse is a product. It's an architecture; Databricks, Snowflake-with-Iceberg, or Trino+Iceberg can all implement it
• Forgetting the copies. Two-tier designs drift: the lake says 1,02,331 rides, the warehouse says 1,02,298
• Ignoring maintenance. Lakehouse tables need compaction and snapshot expiry, or they slow down and storage grows forever

Words to know

In two minutes

• A warehouse manages storage, format and compute for you: schema-on-write, ACID SQL, low ops, higher cost per TB.
• A lake is files on object storage: cheapest, any format, any engine, schema-on-read — but no transactions or updates.
• A lakehouse adds an open table format (Delta, Iceberg, Hudi) on the lake: ACID, MERGE/DELETE, time travel, schema enforcement.
• The classic two-tier design copied lake data into a warehouse; lakehouses aim for one open copy.
• Medallion layers: bronze (raw, append-only) → silver (clean, conformed) → gold (business-ready).
• Start with a warehouse for small SQL teams; move to a lakehouse for huge, unstructured, ML-heavy or multi-engine needs.
• Lakehouses shift work to you: compaction, snapshot expiry, catalog, permissions.

Test yourself

There are 9 questions, 3 puzzles and 5 recall cards for this lesson in the app — the recall cards come back on later days, just before you would forget.