What is a data lakehouse?

The trade-off it resolves

Our data lake vs data warehouse explainer covers the classic choice this pattern grew out of: a data lake stores data cheaply and accepts almost any format, but offers weaker structure and query performance; a data warehouse is fast and reliable to query but is more expensive and rigid about the structure data must be in before it arrives. For years, many organisations ran both — a lake for raw data and flexibility, a warehouse for the curated, query-ready copy — and paid the cost of keeping two systems, and often two copies of the same data, in sync. A lakehouse is an attempt to give both properties on one copy of the data rather than choosing, or duplicating.

What the extra layer actually adds

In a plain data lake, files sit in object storage with no guarantees about consistency — two processes writing at once, or a job failing halfway through, can leave data in a broken or confusing state, and there’s no efficient way to know which rows changed without scanning everything. A lakehouse adds a table layer — sometimes called an open table format — on top of that same file storage, which tracks what data exists, enforces schema and supports the kind of reliable, transactional updates a database provides, all while the underlying files stay in an open format rather than being locked into one vendor’s proprietary storage.

What lakehouses are commonly used for

The pattern is popular because a single, well-governed lakehouse can support several needs at once:

• Business intelligence and reporting — running the kind of fast, structured SQL queries that used to require a separate warehouse.
• Machine learning and AI — training models directly against the same data used for analytics, rather than exporting a separate copy to a different system.
• Data engineering — transforming and curating large, raw datasets before they’re queried, all on the same storage layer.

Where the term came from

Databricks is widely credited with popularising the term “lakehouse,” and it’s the architecture the company built its platform around — see our what is Databricks explainer for how that fits together in practice. The pattern itself is now broader than any one vendor, though: several open table formats and platforms implement lakehouse-style architecture, and it has become a general term for “lake storage plus warehouse-like structure and performance,” rather than a single product.

Where this appears in cert study

Lakehouse architecture and the storage-versus-structure trade-off underneath it are core material in the Microsoft Fabric Data Engineer Associate exam and the AWS Data Engineer Associate exam, both of which expect you to recognise when this pattern fits a described workload better than a plain lake or a plain warehouse. Our /revision library covers that syllabus lesson by lesson. For more on the sheer scale of data these patterns are built to handle, see our what is big data explainer.