Data Engineering/Storage
Data Warehouses, Data Lakes, and Lakehouses
Three storage paradigms with different tradeoffs on schema, cost, and query performance — and how the lakehouse tries to get the best of both worlds.
Where you store data shapes almost everything downstream: what tools can query it, how much it costs, and how flexible your schema can be. The three dominant paradigms — warehouse, lake, and lakehouse — represent different points on the tradeoff between structure and flexibility.
Data warehouses
A data warehouse (Snowflake, BigQuery, Redshift) stores structured data in tables with enforced schemas, optimized for fast SQL analytics. Data is typically cleaned and modeled before it lands. Warehouses excel at ad-hoc analytical queries and BI dashboards but are expensive for storing raw, unstructured, or very high-volume data.
Data lakes
A data lake (raw files in S3, GCS, or Azure Blob, often as Parquet or JSON) stores data in its native or semi-structured form with no enforced schema. Lakes are cheap and flexible — you can dump anything into them — but querying requires a separate engine (Spark, Presto/Trino, Athena) and data quality is only as good as your discipline in organizing it.
- Warehouse: structured, schema-on-write, fast SQL, higher cost per TB, strong governance
- Lake: any format, schema-on-read, cheap storage, requires a separate query engine
- Lakehouse: lake storage + warehouse-like guarantees layered on top
Lakehouses
Table formats like Apache Iceberg, Delta Lake, and Apache Hudi add transactional guarantees (ACID), schema enforcement, time travel, and efficient updates/deletes on top of plain files in a data lake. This 'lakehouse' pattern lets you keep cheap, open, cloud-storage-based data while still getting warehouse-like reliability and performance, and query it from multiple engines (Spark, Trino, Snowflake, DuckDB) without copying it.
Note — Picking one in practice
Most teams don't choose exactly one. A common pattern: a lake (often lakehouse-formatted) as the durable, cheap system of record for raw and intermediate data, with a warehouse (or warehouse-native compute over the same lakehouse tables) serving the final, modeled layer that BI tools query.
The right choice depends on data volume, query patterns, team SQL fluency, and cost sensitivity — not on which term is currently trending. Understanding the tradeoffs matters more than picking a specific vendor.