A modern data architecture that combines the low-cost, flexible storage of data lakes with the performance, ACID transactions, and governance of data warehouses.
The data lakehouse is the dominant data architecture pattern of 2024-2026, and for good reason: it collapsed a decade of expensive two-tier architecture (lake + warehouse, connected by fragile ETL) into a single platform where one copy of data serves BI, ML, streaming, and ad-hoc analytics. The term was coined in 2020 by Databricks in the "Lakehouse: A New Generation of Open Platforms" paper, but the architecture existed before the name — Netflix, Uber, and Facebook were all running de facto lakehouses via Iceberg/Hudi/custom metadata layers on object storage. What Databricks crystallized was the packaging: Delta Lake as the table format + Spark/Photon as the engine + Unity Catalog as governance = "lakehouse". Snowflake, BigQuery, and AWS quickly responded with their own lakehouse plays (Snowflake Iceberg tables, BigLake, S3 Tables), and by 2026 every major cloud warehouse IS a lakehouse in everything but marketing name. The defining technical property: data in open file formats (Parquet) on object storage, governed by an open table format (Iceberg/Delta/Hudi), queryable by multiple compute engines simultaneously. No more "extract from warehouse to lake for ML, then load ML results back to warehouse for BI" dance.
Pre-lakehouse, the typical company had: a data lake (S3 + Parquet + Hive) for data scientists and cheap storage; a data warehouse (Snowflake/Redshift/BigQuery) for BI and analytics; 200 pipeline jobs moving curated data from lake → warehouse on schedule, and another 50 jobs moving feature data warehouse → lake for ML. You paid twice for storage, ran duplicate transformations, had two sources of truth with subtle schema drift, and every new team spent their first month figuring out which system to query. Lakehouse eliminates this: one copy of data in Parquet + Iceberg/Delta on S3, Snowflake queries it, Databricks queries it, Trino queries it, ML pipelines read it directly. Storage cost drops ~50%; the ETL layer between lake and warehouse disappears; governance becomes unified.
A retail client had the classic two-tier: S3 data lake (~400TB Parquet) for data science + Snowflake warehouse (~120TB) for BI. Their daily "warehouse hydration" job copied curated marts from lake to Snowflake, taking 4 hours and $45K/month in Snowflake compute + storage. We migrated to a lakehouse: Iceberg tables on S3 via AWS Glue catalog; Snowflake reads via external Iceberg tables; Databricks reads/writes natively; Trino for ad-hoc; Polaris catalog replaced Glue once GA'd. The hydration job disappeared entirely. Snowflake storage dropped 80% (only metadata now, not duplicated data). BI latency unchanged (Snowflake's Iceberg reader is fast). ML teams could finally join Silver features with Gold BI metrics without cross-system gymnastics. 6-month migration, $35K/month steady-state savings.
A Data Lakehouse is a modern data architecture that merges the best features of data lakes and data warehouses into a single unified platform. Instead of maintaining separate systems for raw data storage (lake) and structured analytics (warehouse), a lakehouse provides both capabilities on a single copy of data.
1990s: Data Warehouse (structured, expensive, governed)
↓
2010s: Data Lake (cheap, flexible, ungoverned "data swamp")
↓
2020s: Data Lakehouse (cheap + flexible + governed + fast)A lakehouse stores data in open file formats (Parquet, ORC) on cheap cloud object storage (S3, GCS, ADLS), but adds a metadata/transaction layer that provides warehouse-like features:
| Layer | Technology |
|---|---|
| Storage | Cloud object storage (S3, GCS, ADLS) |
| Table Format | Delta Lake, Apache Iceberg, Apache Hudi |
| Query Engine | Spark, Trino, Presto, Snowflake, DuckDB |
| Governance | Unity Catalog, AWS Glue, Hive Metastore |
| Platform | Table Format | Key Feature |
|---|---|---|
| Databricks | Delta Lake | Unity Catalog, Photon engine |
| Snowflake | Iceberg Tables | Managed Iceberg, Unistore |
| AWS | Iceberg on S3 | Athena, Glue, EMR integration |
| Google Cloud | BigLake | Cross-cloud analytics |
| Dremio | Iceberg | Open lakehouse, Arrow-based |
Lakehouse adoption gotchas:
A data lakehouse is a data architecture that stores all your data (structured, semi-structured, unstructured) in open file formats like Parquet on cheap cloud object storage (S3/ADLS/GCS), while adding warehouse-like capabilities (ACID transactions, schema enforcement, time travel, fine-grained governance) through an open table format layer — Apache Iceberg, Delta Lake, or Apache Hudi. Multiple compute engines (Spark, Trino, Snowflake, Databricks SQL, DuckDB) query the same data directly, eliminating the need to duplicate data between a lake and warehouse. The term was coined by Databricks in 2020, but the architecture pattern now underlies every major cloud data platform — Databricks Lakehouse, Snowflake Iceberg tables, AWS S3 Tables, Google BigLake, Dremio, Starburst. In 2026, lakehouse is the default greenfield architecture; pure warehouses and pure lakes are legacy patterns.
A traditional data warehouse (Snowflake internal tables, BigQuery native, Redshift) stores data in a proprietary internal format optimized for SQL analytics — you give the warehouse your data and only its compute engine can query it. A lakehouse stores data in open formats (Parquet + Iceberg/Delta) on object storage you own — any compatible engine can query it directly. Lakehouses cost less at storage tier (~5-10x cheaper than warehouse-internal storage), eliminate vendor lock-in at the data layer, and unify BI + ML + streaming on one copy of data. Warehouses still beat lakehouses marginally on point-query latency, semantic modeling integration, and operational simplicity (no maintenance jobs to schedule). In 2026, most new projects default to lakehouse; warehouses remain common for small-team analytics where operational simplicity outweighs storage cost.
Yes — Databricks invented the term and offers the most mature commercial lakehouse platform. The Databricks Lakehouse Platform stacks: Delta Lake as the open table format; Apache Spark + Photon as the vectorized compute engine; Unity Catalog for governance (RBAC, lineage, discovery, Delta Sharing); Databricks SQL for BI workloads; MLflow + Mosaic AI for ML/LLM workloads; Workflows for orchestration. In 2024-2026 Databricks added Uniform (Delta ↔ Iceberg compatibility for cross-engine reads), Lakebase (operational Postgres), and expanded Unity to support Iceberg natively, effectively supporting both Delta and Iceberg under one governance umbrella. If you want a single-vendor, opinionated lakehouse stack with strong Spark/ML integration, Databricks is the most complete option in 2026.
Snowflake started as a cloud data warehouse and has steadily evolved into a lakehouse. The key pivot was Snowflake Iceberg tables (GA 2024), which let Snowflake read and write Apache Iceberg tables directly on customer-owned S3/ADLS/GCS storage — with Snowflake compute performance and open storage format. Two modes: Snowflake-managed (Snowflake owns the catalog, files on your storage) and externally-managed (you own the catalog via AWS Glue, Polaris, or REST Catalog). Snowflake also contributed Apache Polaris, an open-source Iceberg REST catalog. Plus: Snowflake supports unstructured data (Document AI), streaming ingest (Snowpipe Streaming), ML (Snowpark, Cortex AI), and open governance (Horizon). In 2026, Snowflake is a lakehouse — it runs internal and Iceberg tables side-by-side, and the trend is toward Iceberg as the default for new large tables.
Three open table formats dominate in 2026: **Apache Iceberg** (Netflix-origin, Apache top-level project, broadest engine support — Snowflake, BigQuery, Databricks, Spark, Trino, Flink, DuckDB all have first-class support; REST Catalog for interop; partition evolution; hidden partitioning; the clear market leader); **Delta Lake** (Databricks-origin, Linux Foundation, deepest Databricks integration with Photon + Unity + Predictive Optimization; Uniform provides Iceberg-read compatibility; strong Structured Streaming support; best choice for Databricks-centric shops); **Apache Hudi** (Uber-origin, optimized for streaming upsert-heavy workloads; Copy-on-Write vs Merge-on-Read table types; native incremental queries; niche but strong for CDC ingestion). Rule of thumb: pick Iceberg for new multi-engine lakehouses, Delta for Databricks-heavy environments, Hudi for high-throughput streaming upserts.
For most new builds in 2026, no — the lakehouse replaces the warehouse. BI on Iceberg via Snowflake/Databricks SQL/Trino is fast enough for dashboards; ML trains directly on lake data; streaming writes to lakehouse tables with ACID. The old dance of "ETL curated data from lake to warehouse" disappears. Exceptions where a warehouse still makes sense: (1) highly interactive BI on small-to-medium datasets where warehouse point-query latency beats lakehouse by a meaningful margin; (2) teams without data engineering capacity to manage Iceberg/Delta maintenance (compaction, expiration); (3) heavy reliance on warehouse-native features (Snowflake Cortex Search, BigQuery ML) not yet lakehouse-native. But in 2026, the modern warehouse IS a lakehouse — Snowflake does Iceberg, Databricks does Delta+Iceberg, BigQuery does BigLake. The distinction is collapsing.
The medallion architecture organizes lakehouse data into three zones: **Bronze** (raw, as-ingested from sources — Kafka, CDC, files, APIs); **Silver** (cleaned, deduplicated, validated, joined entity tables — the canonical business data model); **Gold** (aggregated, business-ready marts designed for specific BI dashboards, ML features, or reports). Each layer is its own set of Iceberg/Delta/Hudi tables in separate schemas or databases. Pipelines flow Bronze → Silver → Gold, typically via dbt, Spark, or Databricks Workflows. This pattern is the de facto standard for organizing lakehouse data: Bronze is the source-of-truth replay layer, Silver is the single-version-of-truth business model, Gold is the consumer-facing marts. Databricks popularized the naming; the pattern itself predates lakehouses (similar to raw/staging/intermediate/marts in dbt, landing/integration/presentation in Kimball). See the medallion-architecture glossary entry for implementation details.