A modern data architecture that combines the performance and governance of data warehouses with the low-cost and flexibility of data lakes.
Lakehouse architecture is what you get when you stop maintaining a data lake and a data warehouse as two separate systems and instead run warehouse-grade SQL, governance, and transactions directly on top of cheap object storage. The term was popularized by Databricks around 2020, but the actual shift has been slow and messy — every vendor has a different spin, and the boundaries between lakehouse, warehouse, and lake have blurred to the point where in 2026 most modern platforms are "lakehouse-shaped" whether they say so or not. Snowflake with Iceberg tables is a lakehouse. Databricks with Delta is a lakehouse. BigQuery with BigLake is a lakehouse. Even DuckDB + Iceberg + S3 is a lakehouse. The common thread: data in open file formats (Parquet) on object storage, with a table format (Iceberg, Delta, Hudi) providing ACID guarantees, and multiple compute engines able to read/write the same tables.
The two-system problem is real. Before lakehouses, most orgs had: (1) a data lake with raw data, Spark jobs, and ML workloads, and (2) a separate data warehouse with curated business tables for BI. Data had to be copied from lake to warehouse via ETL, leading to staleness, reconciliation issues, and duplicate governance. Lakehouses let you keep one copy of curated data, query it from BI tools (via Trino/Snowflake/Databricks SQL) and ML tools (via Spark/PyTorch/Ray) simultaneously, with consistent governance via a catalog (Unity, Polaris, Glue).
A healthcare client had Databricks running ML workloads on S3 Parquet and Snowflake running BI on a copy of the same data — nightly Fivetran jobs kept them in sync at ~$60K/month, with regular reconciliation failures because late-arriving data in the lake didn't match the warehouse for 12-36 hours. We migrated to an Iceberg-on-S3 lakehouse with Snowflake external Iceberg tables and Databricks SQL pointing at the same tables. ETL copying cost dropped to $0 (one copy of data), Snowflake storage cost dropped 60% (external tables bill only metadata), BI and ML became same-second consistent, and Unity Catalog enforced column-level PHI masking uniformly for both engines. Lakehouse architecture paid for itself in 4 months from eliminated duplicate storage and copy-jobs alone.
The Lakehouse Architecture is a modern data platform design that unifies the best of data warehouses (ACID transactions, governance, fast SQL) with the best of data lakes (low-cost storage, open formats, support for ML/AI workloads). It emerged because organizations were tired of maintaining two separate systems and copying data between them.
Traditional Architecture:
Sources → Data Lake (cheap, messy) → Data Warehouse (expensive, clean)
↑ ETL copies data
Lakehouse Architecture:
Sources → Lakehouse (cheap storage + warehouse features)
One system, no data copyingData lakes were cheap but unreliable (no ACID, no schema enforcement — the 'data swamp' problem). Data warehouses were reliable but expensive and locked to proprietary formats. The lakehouse combines both by adding a metadata and transaction layer on top of cheap object storage.
The lakehouse architecture sits on three layers:
| Feature | Data Warehouse | Data Lake | Lakehouse |
|---|---|---|---|
| Storage Cost | High | Low | Low |
| ACID Transactions | Yes | No | Yes |
| Schema Enforcement | Yes | No | Yes |
| Open Formats | No (proprietary) | Yes | Yes |
| ML/AI Support | Limited | Good | Good |
| SQL Performance | Excellent | Poor | Good |
| Data Types | Structured only | All types | All types |
| Governance | Strong | Weak | Strong |
| Platform | Table Format | Key Strength |
|---|---|---|
| Databricks | Delta Lake | ML + engineering unified |
| Snowflake | Iceberg Tables | SQL performance + ease of use |
| Google BigQuery | BigLake (Iceberg) | Serverless + multi-format |
| AWS | Iceberg on S3 + Athena | Native AWS integration |
Lakehouse traps that show up in real deployments:
expire_snapshots and remove_orphan_files regularly.A data lakehouse is one data platform that combines the low cost and flexibility of a data lake (open file formats on cheap object storage like S3) with the reliability, SQL performance, and governance of a data warehouse (ACID transactions, schema enforcement, fast queries). The key enabler is an open table format — Apache Iceberg, Delta Lake, or Apache Hudi — which sits on top of Parquet files and provides a transaction log, per-file statistics, and schema metadata. With a lakehouse you store data once in open formats, then query it from multiple engines (Spark for ML, Trino for BI, Snowflake for ad-hoc, Flink for streaming) without copying. Typical stack: Parquet + Iceberg on S3 + Unity Catalog or Polaris + Databricks SQL / Trino / Snowflake.
Data warehouse: closed/proprietary storage format, compute tightly coupled to storage (though separable in cloud warehouses), single-engine querying, strongest SQL performance and governance, higher storage cost (~$23-40/TB/month). Lakehouse: open storage format (Parquet + Iceberg/Delta/Hudi), object storage at $5-23/TB/month, multi-engine querying (one copy of data queried by Spark, Trino, Snowflake, Databricks SQL, etc.), ACID and governance via table format + catalog, SQL performance approaching warehouse on most workloads. The lakehouse wins on cost, vendor flexibility, and multi-workload support (BI + ML + streaming). The warehouse wins on simplicity and single-vendor support contracts. In 2026 the distinction is fading — most new architectures pick a lakehouse flavor but may route certain workloads through a warehouse engine.
Snowflake is historically a cloud data warehouse, but since 2023-24 it has added lakehouse capabilities via Iceberg tables (external or Snowflake-managed), Polaris Catalog (Apache Polaris, an Iceberg REST catalog Snowflake contributed to open-source), and external table features. With Iceberg tables, you store Parquet in your own S3/ADLS bucket in open Iceberg format; Snowflake queries it at near-native performance, and other engines (Spark, Trino, Databricks) can read/write the same tables through Polaris. That makes a Snowflake-based stack lakehouse-shaped. Pure Snowflake-managed internal tables remain in proprietary format. Pick based on whether you need multi-engine read/write (use Iceberg tables) or just Snowflake-internal compute (internal tables are simpler and slightly faster).
Choose a data warehouse (Snowflake-internal, BigQuery, Redshift) if: (1) all workloads are SQL analytics and BI, (2) you have one analytics vendor and don't need multi-engine access, (3) team is small and simplicity matters, (4) you don't do ML or unstructured data at scale. Choose a lakehouse (Iceberg/Delta on S3 + Databricks or Trino or Snowflake-external) if: (1) you run both BI and ML, (2) you want to avoid vendor lock-in and own your data format, (3) you have large datasets where storage cost matters, (4) you have multiple teams using different engines. Most 2026 mid-to-large data platforms adopt lakehouse for core data with warehouse engines (Snowflake, Databricks SQL) layered on top — getting both open format and warehouse-grade UX.
The catalog is the lakehouse's metadata control plane. It tracks: which tables exist, their schemas, where their files live, which snapshot is current, and who can access what (RBAC, column/row-level security). Without a catalog, a lakehouse is just a pile of Parquet files. Key catalogs in 2026: Databricks Unity Catalog (tightest Databricks integration), Apache Polaris / Snowflake Polaris (Iceberg REST catalog, multi-engine), AWS Glue Data Catalog (AWS-native, wide engine support), Apache Nessie (Git-like branching for data). The Iceberg REST Catalog API (standardized in 2023) lets engines discover/query Iceberg tables from any compliant catalog — reducing catalog lock-in. Plan catalog choice carefully: data is portable between catalogs, but migrating production catalogs is a multi-week project.
Ideal lakehouse workloads: (1) mixed BI + ML where the same curated tables feed dashboards and training jobs; (2) large-scale analytics (> 10TB) where storage cost dominates; (3) streaming + batch unified (Flink writes Iceberg, Trino queries it immediately); (4) data sharing across teams with different preferred engines; (5) regulated industries (healthcare, finance) that need open formats for auditability and long-term archival; (6) ML feature stores where training reads historical snapshots (time travel) and serving reads current state. Less ideal: (1) sub-second interactive dashboards on small data (just use a warehouse or cache); (2) high-concurrency OLTP-style workloads (lakehouses optimize for append-heavy, not point updates); (3) small teams who want one vendor and simplicity — a managed warehouse is less operational overhead.
Real costs: (1) operational complexity — you now manage object storage, catalog, compute engines, metadata maintenance (OPTIMIZE, VACUUM, compaction) separately; (2) multi-engine consistency requires discipline — governance enforced at the catalog layer can be bypassed at the storage layer if IAM isn't tight; (3) small-files and metadata-growth issues need ongoing maintenance jobs; (4) table format version pinning — upgrading Iceberg/Delta versions across producers and consumers is coordination-heavy; (5) cost attribution across compute engines, storage, and catalog is harder than a single warehouse bill; (6) smaller vendor ecosystem for connectors vs mature warehouses; (7) streaming writes + concurrent batch writes can conflict and need retry logic. The lakehouse is a better architecture for scale, but it's more DIY than a turnkey cloud warehouse — budget for platform engineering headcount to run it properly.