Data lake versus data warehouse

WHAT THIS TESTS This checks foundational understanding of two storage paradigms and the judgment to pick the right one for a workload.

A GOOD ANSWER COVERS A data warehouse stores structured, cleaned, and modeled data using schema-on-write, meaning the schema is defined and enforced before loading, which makes SQL and business intelligence queries fast and consistent but requires upfront modeling and tends to cost more per gigabyte. A data lake stores raw data of any shape, structured tables, JSON, images, logs, on inexpensive object storage using schema-on-read, where structure is applied at query time, giving flexibility for diverse and evolving sources at very low storage cost. The tradeoff is that lakes need governance and good cataloging or they degrade into unusable data swamps, and ad hoc query performance can be worse without optimization. You choose a lake when sources are varied or unstructured, volumes are huge, you want to ingest first and decide schema later, or you are feeding machine learning and exploratory analytics. You choose a warehouse when consumers need fast, governed SQL over well-defined business metrics. Many teams combine both in a lakehouse.

COMMON WRONG ANSWERS Saying they are interchangeable. Claiming a lake replaces a warehouse entirely, ignoring BI performance needs. Describing the difference only as cheap versus expensive without mentioning schema-on-read versus schema-on-write. Forgetting governance, which is what separates a usable lake from a swamp.

LIKELY FOLLOW-UPS What is a lakehouse. How do you prevent a data swamp. How does query performance differ.

ONE CONCRETE EXAMPLE A startup ingests clickstream JSON, product images, and order tables into an S3 data lake to keep raw data cheaply and train ML models, then loads curated daily sales aggregates into a warehouse so analysts get fast, reliable dashboards.