TL;DR. The format war is effectively over, and the old architecture argument ended with it, by relocating: warehouses now read and write open table formats, lakehouses now ship warehouse-grade SQL engines, and one copy of data in object storage serving multiple engines is the converged shape. What remains of "lakehouse vs warehouse" is a real but narrower question: which engine, whose catalog, and what workload mix. BI-heavy, governance-mature, high-concurrency estates still fit warehouse engines best; mixed SQL-plus-ML workloads on one copy of data are the lakehouse's home game. The catalog, not the table format, is where the lock-in now lives.
Few comparisons in data architecture have aged as fast as this one. When the lakehouse was named, the warehouse and the lake were genuinely different places: proprietary tables inside an engine on one side, raw files and hope on the other. Six years later, the technical ground the comparison stood on has largely dissolved, and an honest treatment has to say so before it says anything else. This article covers what the lakehouse is, what actually converged, and the narrower, still-real decision that remains. It assumes the fundamentals of the warehouse and the four-way vocabulary from warehouse vs mart vs lake.
Quick answer
If your analytical estate is BI-dominated, concurrency-heavy, and governance-mature, a warehouse engine remains the lower-friction center, and it can now do so on open formats that keep your storage portable. If your estate genuinely mixes large-scale SQL analytics with machine learning and data engineering on the same data, the lakehouse stack earns its keep by serving both from one copy. And if you are choosing today, the architectural question has mostly become a platform question: every serious contender offers both postures, and the deciding variables are engine fit, catalog ownership, and billing shape rather than storage religion.
What the lakehouse is, and where it came from
The term was coined and popularized by Databricks in a January 2020 blog post and formalized a year later in a CIDR 2021 paper by Armbrust, Ghodsi, Xin, and Zaharia, which argued that two-tier architectures, a lake for raw data plus a warehouse for curated data, were unsustainable: two copies to keep consistent, warehouse data perpetually stale against the lake, and machine learning locked out of the curated tier. The proposed cure was warehouse-style table management (transactions, schema enforcement, time travel) implemented directly on open files in object storage. The paper is vendor-authored research and its performance claims should be read that way, but its diagnosis of two-tier pain was real and widely felt.
The mechanism that made the idea practical is the open table format: a metadata layer that turns a directory of Parquet files into a table with ACID semantics. Three emerged (Delta Lake from Databricks, Apache Iceberg from Netflix via the Apache Software Foundation, and Apache Hudi), and the decisive fact of the past few years is that Iceberg became neutral infrastructure: an Apache top-level project since 2020, adopted far beyond its origins. By 2024 the format war had peaked visibly, with Databricks acquiring Tabular, the company founded by Iceberg's creators, in a deal press reports put north of a billion dollars, and Amazon shipping S3 Tables, object storage with managed Iceberg built in. Formats stopped being sides and became plumbing.
The convergence, from both directions
What makes the classic comparison obsolete is that both camps crossed the line from opposite sides.
The warehouses opened up. Every major warehouse engine now reads Iceberg tables sitting in customer-owned object storage, and, as of late 2025, all of them write it in some form: Snowflake's managed Iceberg tables are generally available with full DML, BigQuery's arrived GA with catalog integration (partitioning still in Preview), and Redshift shipped append-only Iceberg writes in November 2025. A warehouse whose tables are open files in your own buckets is not the proprietary silo the lakehouse paper indicted.
The lakehouses grew warehouse manners. Dedicated SQL engines over lake storage now ship the things warehouse buyers take for granted: serverless warehouses, cost-based optimizers, workload isolation, and catalog-level governance with lineage and audit. The dedicated comparison of storage architectures covers the taxonomy; the point here is that "lakehouse" no longer means giving up warehouse ergonomics, and "warehouse" no longer means giving up open storage.
What did not converge is the layer above the files: the catalog. As formats opened, the competitive moat moved up one level, into the catalogs that hold table metadata, permissions, and lineage. Whose catalog owns your tables now determines engine interoperability in practice, which engines can write and not merely read, and what leaving costs. Even format-neutral gestures carry catalog gravity, a point competitors make loudly and vendors demonstrate by making their catalogs the non-optional center of their open-format stories. The war did not end; it relocated.
Where each still wins
The remaining differences are workload differences, and they are real enough to decide architectures honestly.
Warehouse engines still win BI-shaped work. High-concurrency dashboard estates, sub-second interactive slicing, mature row- and column-level policy, and the operational simplicity of an engine that has done exactly this for a decade: this is the warehouse's home game, and the lakehouse paper itself conceded governance and latency as the incumbent's strengths. An organization whose analytical life is dimensional models feeding BI tools gains little from re-platforming that estate onto lake infrastructure, especially now that open formats remove the old portability argument for doing so.
Lakehouse stacks win mixed workloads on one copy. Where the same data feeds SQL analytics, feature engineering, model training, and streaming, the one-copy architecture stops being a slogan and starts being an operating cost advantage: there are no synchronization pipelines between a lake and a warehouse and no staleness gap, and governance happens on a single surface. This was the CIDR paper's strongest argument and it has held up. Estates with genuine ML gravity, or with heavy semi-structured and streaming ingestion, fit the lakehouse shape natively rather than by accommodation.
Cost profiles differ by workload rather than by architecture. Lake storage is cheap everywhere now, warehouses included; compute pricing follows the billing-shape logic of the engines involved rather than the storage layer underneath. The durable cost claim is narrower than either camp's marketing: paying twice to store and synchronize two copies of the same data is the thing the converged architecture actually eliminates.
Decision criteria
Choose a warehouse-engine center when BI concurrency and governance maturity dominate, the team's fluency is SQL and dimensional modeling, and ML workloads are peripheral or well-served elsewhere; insist on open-format tables and an exportable catalog so the choice stays reversible. Choose a lakehouse center when ML and engineering workloads share the data with analytics at comparable weight, when streaming and semi-structured ingestion are first-class, or when a two-tier lake-plus-warehouse estate is already imposing the synchronization tax the architecture exists to remove. In both cases, ask the catalog question before the engine question: which catalog owns the tables, which engines can write through it, and what the answer does to your exit economics. And treat any performance number from either camp as positioning; the benchmark dispute between the two loudest vendors ended with both sides declaring victory and no neutral referee, which tells you everything a buyer needs to know about its decision value.
Sources
The founding documents are Databricks' What Is a Lakehouse? (January 2020, vendor-authored, where the term was popularized) and Armbrust, Ghodsi, Xin, and Zaharia, Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics (CIDR 2021; vendor-authored research, performance claims labeled accordingly). The neutral anchor for the format layer is the Apache Iceberg project (Apache top-level project since 2020). Warehouse-side convergence evidence, all vendor documentation current as of mid-2026: Snowflake Iceberg tables, BigQuery managed Iceberg tables, Redshift Iceberg writes (November 2025), and Amazon S3 Tables (December 2024). The Tabular acquisition and its reported price are press reporting (June 2024), attributed as such and summarized with citations in the Apache Iceberg Wikipedia article. The catalog-as-moat dissent is argued, from a competitor's interest and labeled as one, in Onehouse's critique of catalog-gated Iceberg support. Market-size figures and cross-platform TCO comparisons are deliberately absent for want of traceable methodology.
Related
Warehouse vs mart vs lake covers the storage-architecture taxonomy this comparison sits inside. How to choose a data warehouse platform is the decision this comparison usually resolves into, including the catalog and billing axes. The modern warehouse platforms pillar covers the platform generation on both sides of the convergence, and the data lakehouse and Apache Iceberg glossary entries define the primitives.