Data Warehouses & Lakehouses

Interviewers ask about warehouses and lakehouses because the answer reveals whether a candidate has only ever queried an analytics system or has actually had to reason about why it's built the way it is — and that reasoning is what you need the moment something is slow, expensive, or architecturally wrong. A candidate who says "Snowflake is a cloud data warehouse and BigQuery is Google's version" has memorized a product category. A candidate who can explain why a single wide fact table with a billion rows scans in two seconds on a columnar engine but would bring a row-oriented OLTP database to its knees, why separating storage from compute is what lets a warehouse scale a single query across a hundred nodes without moving petabytes of data first, and why an open table format sitting on plain object storage can now offer the transactional guarantees that used to require a proprietary warehouse — that candidate has an architectural model, and it's the model every other subject in this track quietly assumes you already have.

This subject builds that model layer by layer: the workload distinction (OLTP vs OLAP) that explains why analytical systems exist at all, the storage layout (columnar) that makes them fast, the execution architecture (MPP, with storage and compute separated) that makes them scale, and the newest architectural bet (the lakehouse, built on open table formats) that is currently reshaping which of those three systems — warehouse, lake, or lakehouse — a team should actually build on. data-modeling-dimensional-and-normalized covers how you shape data once it's in one of these systems, and file-formats-partitioning-and-storage-layout goes deep on the on-disk formats (Parquet, ORC) this subject only introduces at the concept level; this subject is the architecture that sits underneath both.