A Working Mental Model Before Delta

The lakehouse becomes easier to judge when its parts are connected in one causal model rather than treated as a set of platform features. The pressure is the need to use shared, changing data for BI, engineering, streaming, and machine learning. The enabling condition is open storage that different compute systems can reach. The missing condition is a control layer that decides which objects form a trustworthy table state. Holding those three relationships together lets us distinguish what the lakehouse unifies from what it still leaves to specialized systems.

From workload pressure to a shared logical state

The starting pressure is familiar: data arrives in more forms, more quickly, and must answer more kinds of questions. A warehouse offers strong management and efficient analytical access, but its closed or highly managed storage model can be awkward for large non-SQL workloads and heterogeneous data. A raw lake offers flexible retention and direct file access, but it leaves too much meaning to individual writers and readers. The two-tier compromise connects the two through transformations, and those transformations create new places for delay, duplication, semantic drift, and failure.

The lakehouse does not erase the distinction between storage and computation. It changes where the shared boundary is drawn. The data plane remains a collection of open objects in low-cost storage. The logical table is defined by metadata and transaction state. The compute plane contains SQL, BI, DataFrame, streaming, and machine-learning clients that can use the same table through different access paths. The architecture is unified at the level of data state, not at the level of one universal execution engine.

flowchart LR P["Freshness and reliability pressure"] --> O["Open object storage"] O --> M["Managed metadata and transaction control"] M --> S["Shared logical snapshot"] S --> BI["BI and SQL"] S --> DE["Data engineering and streaming"] S --> ML["Machine learning and data science"] O -.-> D["Direct file access"] M -.-> G["Versions, governance, and optimization"] D -.-> T["Portability and compute choice"] G -.-> T

This model explains why each layer exists. Open storage answers how to retain and move large volumes of data without committing every workload to one service. Metadata and transaction control answer which data is current, which change is valid, and how a reader can identify the intended snapshot. Consumers answer what computation is performed and where. If any one of these questions is left implicit, the architecture falls back toward one of the older compromises: a file lake with conventions, a warehouse that mediates every access, or a two-tier pipeline that synchronizes copies.

The model also separates two meanings of “shared.” The bytes can be shared because several systems can read an open format. The state can be shared because those systems agree on a table protocol. The first is a storage property; the second is a management property.