Lakehouse
An architecture combining a lake's cheap open storage with a warehouse's transactions, schema enforcement and query performance, through a table format layer.
The lakehouse is best understood as a response to a specific and expensive failure: organisations ended up running both a lake and a warehouse, copying data between them, maintaining two sets of transformation logic, and reconciling two versions of every number.
The lake was cheap, open and able to hold anything, and it lacked transactions, schema enforcement and performance, which is how the phrase "data swamp" entered the vocabulary. The warehouse had all three and imposed proprietary storage, expensive scaling, and poor support for the unstructured and semi-structured data that machine learning needs.
The lakehouse puts an open table format over object storage to supply the missing guarantees, and lets multiple engines — SQL, streaming, machine learning — read the same tables without copies.
The realistic assessment, several years in: the storage and format convergence is genuine and now the default assumption for new platforms. The claim that one system serves every workload is still optimistic — high-concurrency low-latency BI remains a place where a specialised engine earns its cost, and many mature estates run a lakehouse foundation with a serving layer on top rather than a single system.