13.2 Warehouses & Lakes
Data warehouses store curated, schema-on-write tables for BI. Data lakes store raw, schema-on-read files for science. Lakehouses fuse both. This lesson contrasts the three and shows when each is the right choice.
Side-by-side
Dimension Data Warehouse Data Lake Lakehouse Schema On write On read On write where it matters, on read elsewhere Storage Columnar DB Object storage Object storage + ACID layer (Delta, Iceberg, Hudi) Workloads BI, reports Data science, ML BI + ML on one copy Latency Sub-second to minutes Minutes to hours Sub-second to minutes Governance Mature Often weak Mature (table format level) Cost per TB Higher Lowest Mid Examples Snowflake, Redshift, BigQuery, Synapse S3, ADLS, GCS Databricks, Snowflake (Iceberg), Unity, Onehouse
Picking The Right Pattern
Situation Pick Finance and ops need certified dashboards Warehouse Data scientists need raw click streams and logs Lake Both audiences, same data, one budget Lakehouse Privacy-sensitive data with strict access policies Warehouse (mature RBAC) Petabyte-scale unstructured archive Lake
Common Mistakes
Treating the lake as the production system - it ingests faster than it serves.
Forgetting indexing on the warehouse - good schemas cannot save a missing index.
Letting the lake become a swamp - every dataset needs an owner and a description.
Skipping table-format choice - Iceberg vs Delta vs Hudi is the most consequential lakehouse decision.
Lesson at a glance
Start
Lesson 53 of 58 · 91%
End
Your progress through the Enterprise Architecture Tutorial track.
📚 Study aids for 13.2 Warehouses & Lakes
Reading is only step one. To lock in 13.2 warehouses & lakes from the Enterprise Architecture Tutorial track, use the interactive tools iwantcoding.com ships with every lesson:
💡 Editor's tip: Learners who complete the flashcards before the boss quiz score, on average, 22% higher on the first attempt. Reading → drilling → testing → building is the order that sticks.
Discussion
Loading…