A data lakehouse is a storage architecture that puts warehouse-style tables on top of the cheap object storage used by a data lake. You still keep your files in something like S3 or Google Cloud Storage, but a table format layer sits over those files and gives you the things you’d normally only get from a data warehouse: a defined schema, transactions, and the ability to update or delete individual rows.
Why the category exists
Before lakehouses, most organizations ran both. Raw and semi-structured data landed in a lake, then ETL jobs copied a cleaned subset into a warehouse for analysts to query. That works, but you end up paying for two storage systems, maintaining the pipelines between them, and answering “why does the warehouse number differ from the lake number?” every quarter.
The lakehouse collapses that. Instead of moving data into a second system to make it queryable, you leave it where it landed and describe it well enough that a SQL engine can treat it like a table.
Table formats and ACID on object storage
The piece that makes this work is the open table format — Apache Iceberg, Delta Lake, or Apache Hudi. Object storage on its own has no notion of a row, a transaction, or a schema change; it just has files. A table format adds a metadata layer that tracks which files belong to which version of a table, so you get:
- ACID transactions. A writer commits a new set of files atomically, so readers never see a half-finished write.
- Time travel. Old snapshots are retained, so you can query a table as of last Tuesday — which is how you reproduce a report or diagnose a bad pipeline run.
- Schema evolution. You can add, rename, or retype a column without rewriting every file.
- Row-level updates and deletes. Useful for corrections and for honoring deletion requests, which plain Parquet files make painful.
Because a lakehouse writes many small files as data streams in, compaction becomes a routine maintenance job rather than an optimization you get to ignore.
When a lakehouse makes sense
A lakehouse is a good fit if you already have a large lake and want analysts to query it without maintaining a separate warehouse copy, or if you have a mix of structured tables and semi-structured data that you want governed the same way. It’s less compelling if your data is modest in volume and already tidy — a managed warehouse will be simpler to run and usually faster out of the box.
Plenty of organizations still land somewhere in the middle, keeping a lakehouse for large or raw datasets and a warehouse for the curated models that leadership reports run on. Either way, what your BI tool connects to is a query engine sitting over those tables, so from an analyst’s point of view a well-run lakehouse looks like any other analytical database.
Key article
Related terms
Further reading
Put it to work
- Build a data pipeline — Integration
- Cloud cost analytics — Overview
- Cloud spend overview — Dashboard
