A data lakehouse is an architecture that runs warehouse-style workloads (reliable tables, transactions, SQL, governance) directly on the cheap object storage of a data lake. One copy of the data, stored in open file formats on S3, ADLS, or GCS, serves the jobs that used to require two separate systems: BI dashboards that wanted a warehouse, and data science or ML workloads that wanted a lake.
The architecture exists because the two-system world it replaced was expensive in a specific, familiar way. The warehouse held curated, reliable tables for analysts; the lake held everything else (raw files, logs, images, training data) for engineers and scientists. Keeping them meant duplicating data, running pipelines to shuttle between them, reconciling the inevitable drift, and paying for both. The lakehouse bet is that one platform can be reliable enough for finance and flexible enough for ML, and the bet has largely paid off for batch analytics.
The enabling technology is the open table format: Delta Lake, Apache Iceberg, and Apache Hudi. These add a transactional metadata layer over Parquet files in object storage, which is what turns a folder of files into a table. ACID transactions, schema enforcement and evolution, time travel to past versions, and safe concurrent writers: the properties whose absence made first-generation data lakes degrade into "data swamps." The format wars have consolidated meaningfully, with Iceberg emerging as the broadly adopted neutral standard and Delta dominant inside the Databricks ecosystem, and the major platforms now reading and writing both.
The architectural consequence is the separation that matters: storage, table metadata, and compute become independent layers. Data lives once, in an open format the organization controls. Any engine that speaks the format (Spark, Trino, Snowflake, BigQuery, DuckDB, a Python process) can query the same tables. That is the real strategic content of the lakehouse pitch: the end of data held hostage by the engine that loaded it.
This page covers how the architecture works, what it replaced and why, the medallion organization pattern most teams use, where the lakehouse genuinely wins, and where a classic warehouse remains the more honest choice.
The warehouse era optimized for one customer: the analyst with SQL. Structured data, heavily modeled, reliably governed, expensively stored. It worked, and still works, until the workloads diversify: the data science team needs raw event history, the ML pipeline needs images and text, and the volumes make warehouse storage pricing painful. The warehouse's answer to unstructured data at scale was, essentially, "not here."
The data lake era answered with object storage: land everything, cheap and schema-free, decide later. The economics were right and the reliability was absent. No transactions meant readers saw half-written data. No schema enforcement meant every consumer parsed defensively. No update or delete meant compliance requests turned into file-rewriting projects. The pattern's epitaph, "data swamp," was earned: lakes became write-only archives nobody trusted enough to read.
So organizations ran both, and the tax compounded. Every dataset that mattered existed twice, with pipelines shuttling between lake and warehouse and engineers reconciling the drift. Governance applied in one place but not the other. Two security models, two cost centers, and a permanent argument about which copy was current. The two-system architecture was nobody's design; it was the residue of two eras of tooling, and it was the actual status quo the lakehouse displaced.
The displacement worked because the table formats fixed the lake's disqualifying flaws in place. ACID transactions on object storage meant finance-grade reliability without moving the data. Schema enforcement meant tables, not file conventions. Updates and deletes meant GDPR compliance without rewriting partitions by hand. The lake kept its economics and gained the warehouse's discipline, which collapsed the reason for the second system.
The honest caveat is that the convergence ran both directions. While lakehouses gained warehouse reliability, warehouses gained lakehouse features: Snowflake and BigQuery now query and manage Iceberg tables in your object storage, blurring the category line. The practical question in 2026 is rarely "lakehouse or warehouse" as products; it is whether your data lives in open formats you control, and which engines you let compute over it.
The foundation is object storage, and its properties drive everything above. S3, ADLS, and GCS offer effectively unlimited capacity at the lowest storage prices in the stack, with durability the warehouse era could not buy. Their constraint, no in-place file updates and no transactional semantics, is precisely the gap the table format exists to bridge.
Files are almost universally Parquet: columnar, compressed, predicate-friendly. The table format adds the metadata brain on top: a transaction log or snapshot tree recording which files constitute the table right now, what its schema is, and how it has changed. A query against an Iceberg table starts by reading metadata, learns it can skip 97% of the files via partition and column statistics, and reads only the remainder. Most of lakehouse query performance is this metadata-driven file skipping, which is why table maintenance matters so much in operation.
The transactional mechanics are snapshot-based. Writers prepare new files, then atomically commit a new table version pointing at them; readers always see a consistent snapshot, never a half-write. Old snapshots persist until expired, which yields time travel (query the table as of Tuesday) and cheap rollback (re-point to the pre-bug version). Concurrent writers conflict-check at commit time. These are the properties that turned "files in a folder" into something a finance team can close books on.
Compute attaches per workload, which is the architecture's quiet superpower. Spark for heavy transformation and ML pipelines, Trino or an engine-native SQL layer for interactive analytics, streaming writers for continuous ingestion, DuckDB on a laptop for local exploration, all against the same tables with no copies. A catalog (Unity Catalog, AWS Glue, Polaris, and peers) sits beside the formats as the source of truth for what tables exist and who may touch them, and catalog choice has become the real point of platform gravity, since whoever controls the catalog controls access.
Operations is the layer the brochures omit. Streaming and frequent small writes produce small-file proliferation that degrades scans; compaction jobs must consolidate them. Snapshots accumulate and need expiry; unreferenced files need cleanup; statistics need refreshing. Managed platforms automate much of this and charge accordingly; self-managed lakehouses make it the platform team's chore. Skipping table maintenance is the modern way to rebuild the data swamp, one small file at a time.
Most lakehouses organize data in three refinement layers, the medallion convention. Bronze: raw ingested data, kept as-is, the permanent landing zone and replay buffer. Silver: cleaned, deduplicated, conformed entities (the lakehouse home of those mastered customers and validated events). Gold: aggregated, consumption-shaped tables feeding dashboards, reports, and features. The names are arbitrary; the discipline (raw preserved, cleaning explicit, consumption insulated from sources) is the same ELT logic, given a floor plan.
Bronze earns its storage cost as insurance. Because raw data persists in full, any bug discovered in silver or gold logic is repaired by replaying from bronze, the same recovery property that raw staging gives ELT and replayable streams give ingestion. Teams that trim bronze to save pennies rediscover its purpose during their first serious transformation bug, at much worse prices.
Ingestion meets the lakehouse at bronze, in both tempos. Batch loads and CDC streams land continuously; table formats absorb streaming writes natively (with the small-file consequences noted above), and the lakehouse increasingly serves as the durable end of real-time pipelines. The one-platform effect is that streaming events, operational extracts, and bulk files all become tables under the same governance, rather than three estates with three rulebooks.
Transformation across the layers is standard ELT practice: SQL or Spark in version control, dependency-ordered, tested, with dbt and its peers as common on lakehouses as on warehouses. The difference from warehouse ELT is reach: the same pipeline graph that builds finance's gold tables also builds ML training sets and feature tables, because the platform underneath does not distinguish the customers.
ML and AI workloads are where the single-platform argument cashes out. Training data assembly reads silver history directly, no export to a separate lake. Feature pipelines write feature tables next to BI tables, under the same lineage and access controls. Unstructured data (documents, images, embeddings for retrieval systems) lives in the same storage estate as the structured tables that reference it. For organizations whose AI roadmap keeps colliding with "the data is in two places and neither is quite right," this consolidation, more than cost, is the purchase rationale.
The clean wins: organizations running both substantial BI and substantial ML on the same data, where two-system duplication was a real tax. Data volumes where warehouse storage pricing dominates the bill and object storage pricing is materially different. Mixed structured and unstructured estates, since the lake half was already mandatory. And organizations with strategic anxiety about engine lock-in, for whom open formats are the exit option made permanent.
The equally honest non-wins: a company whose analytics is SQL dashboards over modest structured volumes is better served by a plain warehouse, full stop. The lakehouse's flexibility is overhead when there is nothing to flex; the warehouse's integrated polish (performance without tuning, governance without assembly) is worth its price at small scale. The lakehouse pitch deck rarely includes the platform engineer it assumes.
Performance parity claims deserve adult skepticism in both directions. Lakehouse SQL engines have closed most of the interactive-query gap, and for large scans over open tables they are frequently cheaper. Hyper-optimized warehouse workloads (high-concurrency BI on curated marts) still tend to run best on the warehouses built for exactly that, which is why the common end state is hybrid: lakehouse as the storage and transformation estate, warehouse engines computing over the same open tables where they earn it. The open formats make this hybrid cheap to run and easy to rebalance, which is the practical payoff of the openness argument.
Operational maturity is the gating factor more than workload shape. A lakehouse is a platform you run (or pay a vendor to run): catalogs, maintenance jobs, access integration, format upgrades. Managed offerings (Databricks, and the lakehouse modes of the major warehouses and clouds) compress this dramatically and re-introduce a softer form of the platform gravity the formats were meant to dissolve, now centered on the catalog. The trade is real and worth making consciously: openness of data is largely secured by the formats; convenience still gets bought with some commitment.
Migration reality, for teams coming from either parent: warehouse-to-lakehouse migrations are transformation-logic projects (the data moves easily; the thousand views and stored procedures do not), and lake-to-lakehouse migrations are mostly table-format adoption plus the governance the lake never had. Both are quarters, not weeks, and both are usually best run as new-workloads-first rather than big-bang, the strangler-fig instinct applied to platforms.
Iceberg's emergence as the neutral standard is the defining ecosystem fact. Snowflake, BigQuery, Redshift, Athena, Trino, Spark, Flink, and DuckDB all read and write it; Databricks, Delta's home, acquired Iceberg's founding company and supports both formats; managed Iceberg catalogs ship from every major cloud. Format choice has cooled from a bet-the-architecture decision to a manageable one, with interoperability layers translating where estates mix.
The competitive center moved to catalogs. When every engine reads every format, the control point is the metadata service that says what exists and who may access it: Unity Catalog, Glue, Snowflake's catalog, the open Polaris and Gravitino projects. Catalog choice now carries the lock-in weight that storage formats used to, and evaluating a lakehouse platform in 2026 is substantially evaluating its catalog's openness, governance depth, and cross-engine reach.
Compute has commoditized downward as well as upward. The same Iceberg table serves a thousand-node Spark job and a DuckDB process on a laptop, and the small end matters more than it sounds: analysts pulling gold tables locally, CI jobs testing transformations against real formats, single-node workloads escaping cluster pricing. The lakehouse quietly ended the era when touching organizational data required organizational compute.
AI workloads are reshaping the roadmap. Vector and embedding storage alongside tables, lineage that covers training sets and feature pipelines, governance that answers "what data trained this model," and lakehouse tables as the grounding corpus for retrieval systems. The lakehouse's claim to be the AI data platform is partly earned and partly marketing, but the direction is unambiguous: the formats and catalogs are growing the metadata muscles that AI governance requires.
What has not changed is the failure mode underneath all of it. A lakehouse with weak modeling, no ownership, and skipped maintenance is a data swamp with ACID transactions, better organized in its unreliability. The architecture removes the technical excuses (the lake can now be governed, transactional, fast), and in doing so it relocates the determining variable to where it always was: whether the organization does the modeling, stewardship, and operational work. The platform is necessary; it has never once been sufficient.
An architecture that stores data once, in open table formats on cheap object storage, and runs warehouse-grade workloads (ACID tables, SQL, governance) and lake-grade workloads (ML, unstructured data) on that single copy.
The warehouse couples storage to its own engine and excels at curated SQL analytics; the lakehouse stores open tables any engine can compute over, covering ML and unstructured workloads the warehouse never served. The line is blurring as warehouses adopt open formats, which is itself the lakehouse argument winning.
The table format. A lake is files and conventions; a lakehouse is transactional tables with schema enforcement, time travel, and safe concurrency over the same storage. The lake's economics, minus the swamp.
Iceberg if you are choosing freshly in 2026: it is the broadly adopted neutral standard with support from every major engine. Delta remains excellent inside Databricks-centered estates, and cross-format interoperability has made the stakes of this choice much lower than they were.
The standard three-layer organization: bronze (raw, as ingested, kept forever), silver (cleaned and conformed entities), gold (aggregated, consumption-ready). Its value is the discipline: raw data preserved for replay, cleaning made explicit, consumers insulated from source chaos.
Yes; lakehouse SQL endpoints serve Tableau, Power BI, and Looker like any warehouse, and interactive performance over gold tables is competitive for most workloads. Very high-concurrency dashboard estates sometimes still earn a warehouse engine, pointed at the same open tables.
On storage, almost always, and substantially at volume. On compute, it depends on workload fit and tuning, same as anywhere. The reliable savings is the abolished duplication: one copy, one pipeline estate, one governance model, instead of lake-plus-warehouse and the reconciliation between them.
A catalog, automated maintenance jobs (compaction, snapshot expiry), access-control integration, and ownership of format and engine upgrades. Managed platforms absorb most of this for a fee; self-managed estates should budget real platform-engineering time. The maintenance is unglamorous and non-optional.
It is the strongest mainstream candidate: training data, features, embeddings, and the structured tables that ground retrieval all live under one governance model, with lineage increasingly covering the ML side. The caveat is universal: AI on a badly modeled, unowned lakehouse inherits the chaos with excellent transactional guarantees.
