For most of the last decade, organizations kept two separate systems for their data. A data warehouse held structured, cleaned-up data for business intelligence and reporting. A data lake held everything else: raw logs, semi-structured JSON, images, sensor data, whatever didn’t fit neatly into rows and columns. Analysts queried the warehouse. Data scientists and engineers wrangled the lake. The two rarely talked to each other without a lot of custom pipeline work in between.

The “lakehouse” is the industry’s attempt to collapse that split into one system. It’s worth understanding why this split existed in the first place, and why so much engineering effort has gone into erasing it.

Why the split happened

Data warehouses like the ones built on proprietary MPP databases were optimized for fast, reliable SQL queries over structured data. They enforced schemas, supported transactions, and gave analysts consistent, well-governed tables. The tradeoff was cost and rigidity: storage and compute were bundled together, schemas had to be defined up front, and unstructured data didn’t fit well.

Data lakes emerged as the cheap alternative, mostly built on distributed file storage like HDFS and later cloud object storage such as S3 or GCS. You could dump any file format at low cost and figure out the structure later, an approach often called “schema on read.” That flexibility came at the price of reliability. Lakes had no built-in transactions, no easy way to update or delete records safely, and no enforced schema, which meant lakes had a well-earned reputation for turning into “data swamps” over time.

What the lakehouse actually changes

The lakehouse architecture keeps data in low-cost object storage, the same as a lake, but adds a transactional metadata layer on top. Table formats like Delta Lake, Apache Iceberg, and Apache Hudi are the key piece here. They track which files belong to which table version, support ACID transactions, allow schema evolution, and enable time travel to query older snapshots of a table.

This matters because it lets a single copy of the data serve both workloads. A data scientist can read raw Parquet files directly for a machine learning job, while an analyst runs a BI query against the same underlying data through a SQL engine, all without a separate ETL pipeline duplicating data between systems. Query engines like Spark, Trino, and increasingly cloud-native warehouses can read these open table formats directly, which decouples the storage layer from any single vendor’s compute engine.

The tradeoffs that remain

The lakehouse model doesn’t eliminate complexity, it relocates it. Instead of managing two systems, teams now manage one storage layer plus multiple table format implementations, each with different levels of maturity, tooling support, and interoperability. Iceberg, Delta Lake, and Hudi have converged on similar capabilities but aren’t fully compatible with each other, so choosing one is still a real architectural decision with lock-in implications, just at a different layer than before.

Performance is also not automatically equivalent to a purpose-built warehouse. Warehouses have spent years optimizing query planners, indexing, and caching for their specific storage engines. Lakehouse query engines are closing that gap, but workloads with very high concurrency or latency-sensitive dashboards can still see a difference depending on the engine and table format involved.

Why it’s worth paying attention to

The broader trend behind the lakehouse is the separation of storage from compute, and the shift toward open, vendor-neutral formats for both. That has implications beyond analytics: it’s easier to point multiple tools, from BI dashboards to ML training jobs to ad hoc SQL, at the same governed dataset without copying it three different ways. For any organization that has felt the pain of reconciling numbers between its warehouse and its lake, that alone is a meaningful simplification, even if it comes with its own new set of decisions to make.