The Data Warehouse: the historical standard
The Data Warehouse emerged in the 1980s to meet a simple need: centralizing structured data from multiple operational systems and making it available for reporting and analysis. Bill Inmon laid the theoretical foundations; Ralph Kimball popularized dimensional modeling (star schema, snowflake schema).
A Data Warehouse is optimized for OLAP (Online Analytical Processing) analytical queries. It stores structured data, carefully modeled into fact and dimension tables. Its main strength: excellent query performance thanks to indexes, partitions, and columnar optimizations.
Modern cloud Data Warehouses
Modern architectures have migrated on-premise DWHs (Oracle, Teradata, IBM DB2) to the cloud. Snowflake, Google BigQuery and Amazon Redshift dominate this market. They separate storage from compute (elastic scaling), offer standard SQL, and integrate natively with BI tools (Tableau, Looker, Power BI). Snowflake was valued at $120 billion at its 2020 IPO, reflecting the market enthusiasm.
The star schema (fact tables at the center, dimensions around them) remains the most common model in analytical DWHs. It optimizes joins for BI queries. The snowflake schema further normalizes dimensions but makes queries more complex.
The Data Lake: store everything, transform later
The Data Lake emerged around 2010 with the popularization of Hadoop and HDFS, then established itself in the cloud with Amazon S3, Azure Data Lake Storage, and Google Cloud Storage. The core idea: store all data in its native format (structured, semi-structured, unstructured) at very low cost, with no schema imposed upfront.
The Data Lake applies the 'schema on read' principle: the schema is only defined when reading and analyzing the data. This is the opposite of the Data Warehouse (schema on write). This flexibility allows ingesting application logs, JSON files, images, Kafka streams, without prior modeling.
The danger of the Data Swamp
Without governance, a Data Lake quickly becomes a Data Swamp: terabytes of undocumented files, without lineage, without verified quality, that become practically unusable. This is the major risk of poorly governed Data Lake initiatives. Teams spend more time searching for and validating data than actually analyzing it.
According to a 2019 Gartner study, 85% of Big Data projects failed to create value. One of the main causes: Data Lakes transformed into Data Swamps due to lack of governance, cataloging, and quality control.
Gartner, 2019The Lakehouse: DWH performance on Lake flexibility
The Lakehouse emerged around 2020 to resolve the limitations of both previous architectures. The concept, formalized by Databricks, combines the flexibility and low cost of the Data Lake with the performance, reliability, and analytical capabilities of the Data Warehouse.
Technically, the Lakehouse relies on open table formats (Delta Lake, Apache Iceberg, Apache Hudi) that add ACID layers, versioning, schema enforcement, and query optimization directly on object storage (S3, ADLS, GCS). You write Parquet or ORC files to an S3 bucket and query them with near-DWH performance thanks to file statistics and embedded indexes.
Delta Lake, Apache Iceberg and Apache Hudi
Delta Lake (created by Databricks, open-source since 2019) is the most widely adopted format in Spark architectures. It offers ACID transactions, time travel (querying past states of data), schema enforcement, and automatic small file optimization (compaction). Apache Iceberg, initiated by Netflix, is preferred in AWS ecosystems (Athena, EMR) and is gaining ground. Apache Hudi, created by Uber, excels in frequent upsert scenarios (CDC - Change Data Capture).
Lakehouse tools: Databricks, Amazon Lake Formation, Azure Synapse
Databricks Data Intelligence Platform is the market reference. It combines Spark, Delta Lake, an ML layer (MLflow), and a high-performance SQL engine (Photon). On AWS, Lake Formation with S3 + Glue + Athena offers a serverless alternative. Azure Synapse Analytics integrates the Lakehouse into the Microsoft ecosystem. Google BigLake enables querying S3 or ADLS data from BigQuery.
The term 'Lakehouse' was formalized in the paper 'Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics' published by Databricks in 2021 (VLDB 2021).
Armbrust et al., VLDB 2021Data Lake vs Data Warehouse vs Lakehouse: key dimensions
Here are the five dimensions on which these three architectures differ fundamentally.
Schema: on write vs on read
The Data Warehouse enforces a strict schema at write time (schema on write): data must conform to the model before loading. The Data Lake defines the schema only at read time (schema on read). The Lakehouse enables both: optional schema enforcement for critical tables, schema on read for exploration zones.
Supported data types
The DWH is limited to structured data (SQL tables). The Data Lake accepts everything: structured, semi-structured (JSON, Parquet, Avro), unstructured (images, videos, logs). The Lakehouse adds native ML/AI workflow support on raw data, enabling models to be fed directly from the Lake.
Cost structure
Storage in a cloud DWH (Snowflake, BigQuery) costs approximately 20 to 40 times more than object storage (S3, ADLS). Data Lakes and Lakehouses use object storage, hence very low storage costs. In return, ad hoc queries on a well-optimized DWH remain faster and less compute-intensive.
How to choose your storage architecture
The choice is not made in theory but based on your concrete needs: volume, data types, usage patterns (BI, ML, streaming), team skills, and budget.
Choosing a pure Data Warehouse
Recommended if: your needs are 100% BI/reporting on structured data, your team is SQL-first without Spark skills, you have strict SLAs on query times. Snowflake and BigQuery are excellent for this profile.
Choosing a pure Data Lake
Recommended if: you store massive volumes of unstructured data (logs, images, audio), your primary use cases are Machine Learning on raw data, and you have a team capable of managing governance.
Choosing the Lakehouse
The Lakehouse is the default choice for new architectures in 2026. Recommended if you want to combine BI and ML on the same platform, benefit from low-cost object storage with DWH-like performance, and preserve raw data with robust governance via open formats.
Anchoring these concepts with spaced repetition
The distinction between Data Lake, Data Warehouse, and Lakehouse is a frequent topic in Data Engineering and Data Architecture interviews. The concepts are clear on the surface but quickly intertwine in practice. Memia's data architecture flashcards let you anchor these distinctions in long-term memory.
The most useful comparisons to master: schema on write vs on read, ACID in a Data Lake (impossible without a format like Delta Lake), Time Travel in Delta Lake, difference between partitioning and clustering in BigQuery.
Frequently asked questions about Data Lake, Data Warehouse and Lakehouse
What is the difference between a Data Lake and a Data Warehouse?
The Data Warehouse stores only structured data with a schema defined upfront (schema on write), optimized for SQL analytical queries. The Data Lake stores any type of data (structured, semi-structured, unstructured) in its native format without prior schema (schema on read), at very low cost.
What is a Lakehouse?
A Lakehouse combines the advantages of a Data Lake (cheap object storage, flexibility, all data types) and a Data Warehouse (ACID transactions, SQL performance, schema enforcement). It relies on open table formats like Delta Lake, Apache Iceberg, or Apache Hudi.
What is a Data Swamp?
A Data Swamp is a Data Lake that has become unusable due to lack of governance: undocumented data, without lineage, without verified quality, without cataloging. Teams no longer know what it contains or how to use it. It is the main risk of a Data Lake without a metadata management strategy.
Delta Lake or Apache Iceberg: which to choose?
Delta Lake is preferred in Databricks and Spark ecosystems. Apache Iceberg is more widely adopted in AWS ecosystems (Athena, EMR, Glue) and benefits from growing support from Snowflake and BigQuery. Both offer ACID, time travel and schema evolution - the choice depends primarily on your cloud and existing tools.
Is Snowflake a Data Warehouse or a Lakehouse?
Snowflake started as a pure cloud Data Warehouse. It is evolving toward the Lakehouse with features like Iceberg Tables (S3 storage + Snowflake queries), but remains primarily positioned as a high-performance analytical DWH.
Does the Lakehouse completely replace the Data Warehouse?
Not yet. For 100% BI/SQL use cases with highly structured data, the pure DWH (Snowflake, BigQuery) offers better performance. The Lakehouse is optimal when combining BI and ML on the same platform. In practice, many organizations maintain both in complementarity.
What is time travel in Delta Lake?
Time travel is the ability to query the past state of a Delta Lake table. For example: SELECT * FROM my_table VERSION AS OF 10 or SELECT * FROM my_table TIMESTAMP AS OF '2026-01-01'. This is made possible by the transaction log that Delta Lake maintains for each write operation.
Next article: Data Governance - definition and implementation