The Lakehouse Is the Modern Data Warehouse

The data warehouse is not a product. It never was. It is an architectural intent, a set of goals that organizations have pursued for nearly four decades. And like every architectural intent, the technology that delivers on it must evolve as the demands of the era change.

For a generation of data leaders, the data warehouse and the relational database became synonymous. That conflation made sense for a time. Today, it is the single biggest obstacle to clear thinking about modern data architecture. The lakehouse is not a challenger to the data warehouse concept. It is its rightful successor, and the first technology stack capable of fulfilling the warehouse's original promise at the scale, variety, and speed that modern organizations actually require.

This blog makes the case for why that distinction matters, and what it means for how you build.

The Data Warehouse Has Always Been an Architectural Construct

Bill Inmon, widely credited as the father of data warehousing, was unambiguous on this point: a data warehouse is an architecture. Not a database product, not a vendor platform, not a nightly ETL job. An architecture. Yet walk into almost any organization today and you will hear the term used to describe something far more specific. "Our data warehouse is down — the nightly load failed." "We need to upgrade our data warehouse." In common usage, the warehouse has collapsed into the product that happened to implement it first.

That collapse is the source of enormous confusion, and it matters more now than it ever has.

The goals that define the data warehouse have been remarkably stable since Inmon articulated them in the 1980s. A data warehouse is centralized, integrated across source systems, subject-oriented rather than transaction-oriented, time-variant so historical analysis is possible, and non-volatile so analytical data remains stable once loaded. Everything in that definition describes architectural intent. None of it specifies a storage format, a query engine, or a vendor.

The Inmon vs. Kimball debate reinforces this point. It is one of the defining intellectual disputes in the history of data management. Inmon's top-down approach called for a single enterprise-wide warehouse as the authoritative source of truth. Ralph Kimball's bottom-up approach built from business-process-oriented data marts that were composed into an integrated whole. Both approaches remain foundational to how data teams think today. Both men were arguing about architecture. Neither was arguing that the relational database was the point. It was simply the best available tool.

From the late 1980s through the 2000s, relational databases (Oracle, Teradata, IBM DB2, and later SQL Server) were the natural implementation substrate for the warehouse. Structured data, rigid schemas, strong ACID guarantees, and SQL as a query language aligned well with the business intelligence and reporting use cases of the era. The star schema, the snowflake schema, the OLAP cube, and the ETL pipeline were all practical responses to the constraints and strengths of the relational model.

The architectural principles underneath them were timeless. The implementation layer was not.

Why the Relational Foundation Started to Crack

The relational data warehouse did not fail because the people who built it made poor decisions. It failed because the world changed in ways that no relational architecture could have anticipated.

The business felt the strain before the technologists had a clean framework for describing it. Analytical data was perpetually stale because overnight batch processes could not keep pace with operational systems. AI and machine learning initiatives stalled because the data they needed (unstructured, high-volume, format-diverse) could not be practically stored or managed in a relational warehouse. Teams began maintaining their own shadow copies of data because the central warehouse could not serve their needs fast enough or flexibly enough. Storage costs grew unsustainable as data volumes scaled.

The technical explanation for these problems is straightforward. Relational databases are optimized for structured data with predefined schemas. As data volumes grow, performance degrades. The architecture was not designed for horizontal scalability at the scale that cloud-era data volumes demand. Unstructured and semi-structured data (logs, documents, images, sensor streams, JSON payloads) cannot be managed efficiently in a system that requires rigid schema definitions upfront.

Organizations responded by building a two-tier architecture: a data lake for raw, flexible storage alongside the existing warehouse for governed analytics. The intent was reasonable. The outcome was a new set of problems. The lake and the warehouse could not share data without copying it, which meant paying twice for storage and maintaining two versions of truth. Data in the warehouse was locked in proprietary formats that external tools and engines could not access directly. And data lakes, without the governance disciplines of the warehouse, had a persistent tendency to become data swamps. Repositories of raw data that no one could reliably find, understand, or trust.

The old relational warehouse had not failed in its goals. It had simply met the ceiling of what its underlying technology could deliver. The architecture was right. The substrate had run out of road.

The Lakehouse Fulfills the Warehouse's Original Promise

The term "Lakehouse" first appeared informally in 2017, but it was the 2021 research paper from UC Berkeley that gave it a formal definition and a concrete architectural blueprint. The argument in that paper was direct: the traditional data warehouse architecture, as then implemented, would be replaced by a new paradigm built on open direct-access data formats, with first-class support for machine learning and data science, and performance competitive with the best proprietary systems.

What the paper described was not a replacement for the warehouse's goals. It was a replacement for the technology delivering on them.

The lakehouse preserves everything that made the warehouse valuable: integration across source systems, strong governance, ACID compliance, reliable and performant querying, and a single source of truth for analytical decision-making. What it adds is the capacity to serve workloads that the relational warehouse could never accommodate: unstructured data, AI and ML pipelines, real-time streaming, and the full spectrum of file types that modern organizations actually generate.

Critically, the lakehouse eliminates the two-tier lake-plus-warehouse problem that defined the prior decade. Rather than maintaining a raw storage layer and a managed analytical layer as separate systems with separate costs and separate governance regimes, the lakehouse unifies them. Low-cost, open object storage serves as the foundation. The full capabilities of a managed warehouse (metadata, governance, ACID transactions, query optimization) are delivered through open formats and decoupled compute.

The five layers of lakehouse architecture (ingestion, storage, metadata, API, and consumption) map directly onto the concerns that data warehouse architects have always had to address. The difference is the infrastructure beneath them: cloud-native, decoupled, open, and designed for a world in which data volumes are measured in zettabytes and analytical workloads include training large language models.

That said, the lakehouse is not a drop-in replacement with no friction. Organizations migrating from established relational warehouses face real work: rethinking ETL pipelines, retraining teams on new tooling, and establishing governance practices that were previously enforced by the warehouse engine itself. The architecture is the right destination. The migration is not trivial.

Open Formats Are the New Foundation

Every architectural era has a foundational technology layer that makes its goals achievable. For the relational data warehouse era, that layer was the relational database engine: the star schema, the OLAP cube, the ETL pipeline. For the lakehouse era, it is open table formats built on top of cloud object storage.

Apache Iceberg gives data teams open, vendor-neutral standard for data management at scale. Row-level updates and deletes, schema evolution, time travel, and partition management were once the exclusive province of proprietary warehouse engines. These are now available through open formats to any compliant compute engine. These are the modern equivalents of the star schema: the implementation primitives that turn an architectural concept into something you can actually build and operate.

The table below maps the relational warehouse era's foundational technologies to their lakehouse-era equivalents:

Data in a lakehouse is stored in open, standardized file formats such as Apache Parquet and ORC. Any compliant compute engine can read and write it directly, without format conversion, without copying, and without vendor permission. Compute and storage are fully decoupled, which means organizations can scale each independently and choose the best engine for each workload.

The debates currently playing out across the open table format ecosystem (Iceberg vs. Delta Lake vs. Hudi, which format fits which use case) are the direct structural equivalent of the Inmon vs. Kimball debates of the 1990s. A discipline is maturing. Implementation details are being worked out. Competing schools of thought are producing better answers through productive tension. History is rhyming.

By 2025, the maturation was evident. Streaming-first ingestion, autonomous query optimization, and catalog-driven governance had moved from differentiating features to baseline expectations. The formats had proven themselves across enterprises at scale. The lakehouse was no longer a theoretical architecture or an early-adopter experiment. It was the operational reality of data teams building for the next decade.

The Industry Has Already Converged

Architecture debates in the data industry tend to run long. This one is over.

Apache Iceberg has emerged as the dominant open table format standard, with native support embedded across every major cloud platform, query engine, and data tooling ecosystem. The breadth of that adoption is significant not because any single platform chose it, but because the ecosystem as a whole converged on it. When a format achieves that kind of cross-ecosystem support, it stops being a technology choice and starts being infrastructure.

The trajectory of Apache Polaris tells a parallel story. Polaris Catalog was co-created by Dremio and donated to the Apache Software Foundation, and it is now a top-level Apache project. This establishes open, vendor-neutral catalog interoperability as an expectation rather than a premium feature. The direction of travel is unambiguous: the proprietary lock-in model that characterized the prior generation of warehouse platforms is losing ground, and open standards are filling the space it leaves.

The analyst community has taken note. Gartner upgraded the lakehouse from "high-benefit" to "transformational," a designation reserved for technologies that have demonstrated proven outcomes at scale across diverse enterprise use cases. The market numbers reflect the same reality: the data lakehouse market is projected to grow from $8.9 billion in 2023 to $66.4 billion by 2033.

The most telling signal of convergence is not any single announcement or market figure. It is the nature of the conversation itself. The ecosystem is no longer debating whether the lakehouse is the right architecture. That question has been answered. The conversation has shifted to how to build one well, on open standards, with the governance, performance, and interoperability that enterprise data teams require. When an industry stops arguing about the destination and starts arguing about the best route, the destination has been decided.

Architecture Endures, Technology Evolves

The data warehouse, as an architectural concept, is alive and well. What it has shed is the relational database as its only viable substrate.

The lakehouse is not a replacement for the data warehouse. It is the data warehouse, finally built on technology capable of delivering its original promise at the scale and variety that the modern data environment actually demands. Open, cloud-native, unified across all data types, and designed from the ground up for the AI workloads that now sit at the center of how organizations create value from data.

The vision that Inmon and Kimball articulated across four decades of debate is being fulfilled at scale, in a way that neither proprietary relational engines nor disconnected data lakes ever could. The goals were always right. The technology has finally caught up.

If your organization is still thinking about the data warehouse as a specific relational product, you are thinking about a particular implementation from a particular era. Separate the architectural intent from the implementation layer, and the path forward becomes clear. The warehouse you were trying to build in 1995 and the lakehouse you should be building today are after the same thing. One of them can actually get you there.

Dremio is built natively on Apache Iceberg and Apache Polaris, delivering the query performance, open catalog, and AI-ready semantic layer that the modern lakehouse requires. Try Dremio Cloud free for 30 days and see what your data warehouse was always supposed to be.