Warehouse vs Lake vs Lakehouse

## What a data warehouse is A data warehouse is an analytical database that **owns its storage**. Data enters through a load or ingest path; the engine converts the rows into its own internal columnar representation, chooses encodings, writes statistics about each chunk of data, and records everything in its own catalog. Only that engine — or a small set of blessed connectors — reads those files. Because the engine controls the layout end to end, it can do things an outsider cannot: enforce the declared schema on every row that arrives, keep min/max statistics so most of the data is skipped at query time, maintain transactional metadata so readers see a consistent table, and enforce access control down to individual columns and rows. Historically the compute lived on the same machines as that storage. Modern cloud warehouses put the bytes on object storage instead and scale compute separately, but the data is still managed as a private, engine-owned format — you cannot point another tool at those files and read them. ## What a data lake is A data lake is **object storage plus a convention**. You write files into a bucket, typically in directory paths that encode a partition scheme such as `/events/dt=2026-08-01/`, and register the interesting ones in a catalog so query engines can discover their location and column types. The files can be columnar (Parquet, ORC), row-oriented (Avro), text (JSON, CSV), or not tabular at all — logs, images, model artifacts. Nothing enforces what is inside a file. A producer can add a field, change a type or write a malformed record and the lake accepts it; the mismatch surfaces later, in someone's query. The compensating virtue is openness: storage is inexpensive and elastic, the file formats are public specifications, and any engine that can read them can read your data. No vendor sits between you and the bytes. ## Schema on write versus schema on read The warehouse validates structure at **load** time — a row that does not match the table definition is rejected or quarantined, so everything already in the table is known to be well-formed. The lake defers structure to **read** time — you land whatever arrives and interpret it when you query. Deferring is what lets a lake absorb semi-structured and unforeseen data cheaply; it also means that data quality problems are discovered by consumers rather than producers, and often by several consumers who each write their own slightly different interpretation. ## Correctness and governance A warehouse table has an owner, a definition, permissions, and usually transactional visibility: a query either sees a write or does not. A plain directory of files has none of that by construction. If a job rewrites a partition while a report is scanning it, the report can read a mixture of old and new files. Concurrent writers can clobber each other. There is no reliable row-level update or delete, which matters as soon as you owe anyone a deletion request. Permissions are storage-level — whoever can read the prefix reads every column in it. ## Cost shape Lake storage is close to the raw price of object storage, and you pay compute only when an engine runs. Warehouse storage carries the vendor's own storage rate plus the compute you buy from that vendor, but the engine's statistics, clustering and caching mean a well-shaped query reads far less data, so the *query* is frequently cheaper than the same query brute-forcing files in a lake. Comparing sticker prices per terabyte answers the wrong question; the real comparison is total cost of the workload you actually run. ## Where each wins The warehouse wins where the schema is known and stable, where many concurrent users need consistent, fast SQL, and where governance is a hard requirement — finance, regulated reporting, executive dashboards. The lake wins as a landing zone for high-volume raw and semi-structured data, for data science and ML that wants files rather than SQL, for long retention of data nobody queries often, and anywhere multiple different engines must read the same bytes. ## Why the line is blurring Most real platforms run both: raw data lands in a lake, curated subsets are loaded into a warehouse, and the warehouse can read the remainder in place through external tables. The lakehouse pattern goes further — it puts an open table-format metadata layer over lake files so they get transactions, schema enforcement and statistics while staying readable by many engines. In an interview it is enough to describe the two ends of the spectrum accurately and note that the middle is where most platforms now sit.