An architecture workshop begins with three columns on a whiteboard: warehouse, lake, and lakehouse. Product names appear underneath. People compare feature lists, preferred languages, and licensing before agreeing which decisions the platform needs to improve.
The discussion sounds technical, but its order is backwards.
A useful architecture must fit the organisation’s data, workloads, governance, skills, delivery approach, cost boundaries, and ability to operate the result. A category name can help describe the outcome. It shouldn’t supply the requirements.
Signs that the architecture discussion started too late
The preferred product was selected before important workloads were identified.- A storage technology is expected to resolve inconsistent business definitions.
- Every dataset is assigned the same pattern regardless of structure, value, or use.
- Open formats are discussed without ownership, security, maintenance, or serving design.
- The semantic and consumption layers are treated as reporting details to decide later.
- The team can describe the target platform but not how it will be supported after launch.
Separate the Decisions Hidden Inside the Label
Warehouse, lake, and lakehouse are useful shorthand, but they don’t identify every responsibility or guarantee the same capabilities across products. Modern platforms increasingly combine storage, SQL, engineering, data science, streaming, governance, and business intelligence experiences.
Before comparing categories, separate four decisions:
01
Storage
Which structures, formats, histories, and volumes must be retained, and who controls their lifecycle?
02
Processing
Which engines and languages must ingest, transform, query, stream, or train over the data?
03
Modelling
Where are data quality, integration, grain, history, business rules, and reusable definitions established?
04
Consumption
How do reports, analysts, applications, data scientists, and AI workloads receive governed data?
A platform may place these responsibilities close together, but they remain distinct decisions. Storing a Delta table doesn’t decide its business grain. Providing a SQL endpoint doesn’t establish conformed dimensions. Connecting a semantic model doesn’t prove that upstream changes were captured completely.
What the Three Categories Contribute
Structured analytical serving
Data warehouse
A relational analytical store designed to integrate and serve structured data, commonly through SQL, dimensional models, governed schemas, and workload-oriented performance features.
Flexible retained data
Data lake
Scalable file or object storage that can retain structured, semi-structured, and unstructured data for multiple processing purposes, often in open or widely supported formats.
Open storage with managed analytics
Lakehouse
An architectural pattern that aims to combine direct access to open lake data with management, reliability, governance, and performance capabilities associated with analytical warehouses.
These descriptions overlap because real platforms overlap. A cloud warehouse may use object storage and open table formats internally. A managed lake can supply transactions, schema controls, SQL access, and optimisation. The product experience and the underlying architecture aren’t always represented by the same label.
| Category | Particularly useful when | Design obligations that remain | Common misinterpretation |
|---|---|---|---|
| Warehouse | Structured analytics, governed relational modelling, SQL development, repeatable BI workloads, and multi-table transactional changes matter | Source integration, dimensional or other serving design, history, orchestration, semantic meaning, and operations | “A warehouse is only a proprietary database for nightly reporting.” |
| Data lake | Varied data, large retained histories, open file access, multiple processing engines, exploration, or data science matter | Cataloguing, quality zones, table management, governance, performance, ownership, and dependable consumption paths | “Putting data in inexpensive storage makes it reusable.” |
| Lakehouse | Teams need direct multi-engine access to lake data alongside stronger table management, SQL analytics, governance, and performance | Workload isolation, table design, optimisation, semantic modelling, security, lifecycle, and product-specific operational knowledge | “A lakehouse removes the need for warehouses, models, or curated serving structures.” |
The right comparison is therefore not “old warehouse or modern lakehouse”. It is which capabilities each workload needs, where those capabilities should sit, and what complexity the team can justify.
The Lakehouse Claim
The term lakehouse became prominent through Databricks and the 2021 CIDR paper Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. The paper argued for an architecture based on open, directly accessible data formats with first-class support for data science and machine learning, alongside warehouse-level management and performance.
That was an architectural claim, not a promise that every implementation would expose identical features. Transaction scope, SQL capability, indexing or optimisation, governance, workload isolation, table formats, engine interoperability, and semantic integration still vary.
Open formats can reduce some forms of lock-in and avoid copies created only to move between compatible engines. They don’t make a complete platform portable. Transformation code, catalogues, permissions, orchestration, optimisation, semantic models, operational procedures, and specialist skills can remain tightly connected to a provider.
Start the Decision with Requirements
The architecture should be traceable to the work it must support:
Data shape and volume: Is the important data relational, event-based, document-like, media, or a combination, and how will it grow?- Workloads and users: Which SQL, BI, engineering, data-science, streaming, application, or AI workloads need governed access?
- Latency and freshness: Which decisions need batch, near-real-time, streaming, or direct operational access?
- Transaction behaviour: Which changes require multi-table consistency, concurrent writes, schema enforcement, or point-in-time recovery?
- Skills and delivery: Which tools and languages can the team develop, review, deploy, troubleshoot, and support?
- Governance and security: Where must ownership, classification, lineage, isolation, access, retention, and audit be enforced?
- Interoperability: Which engines, formats, clouds, partners, and future migrations should be able to use the data?
- Cost and operability: What storage, compute, movement, licensing, monitoring, and support burden is proportionate to the value?
Warehouse-oriented, lakehouse-oriented, and combined routes are possible outcomes of the requirements, not mutually exclusive starting positions.
The diagram has three routes because a combined architecture is often deliberate rather than transitional. A lakehouse may retain source-shaped data and support engineering or data science, while a warehouse supplies a curated relational serving model for SQL and business intelligence. Shared governance and clear contracts matter more than forcing every responsibility into one item.
Modern Architecture Doesn’t Remove Modelling
The principles developed in the articles about warehouse layers, dimensional modelling, historical context, data transformation, and warehouse operations remain relevant regardless of storage technology:
- A source still represents an operational process with its own meaning and limitations.
- Integration still needs identity resolution, shared definitions, quality rules, and reconciliation.
- Facts still need a declared grain before measures can be interpreted safely.
- Dimensions and other descriptive structures still need a history policy.
- Pipelines still need restartability, validation, monitoring, and ownership.
- Consumers still need understandable terminology, measures, hierarchies, and security behaviour.
The physical form can change. Some transformations may run through Spark over open tables. Others may use SQL in a relational warehouse. A semantic model may read files through a specialised engine rather than importing from a database. Those changes can improve scale, flexibility, or efficiency, but they don’t decide the business meaning.
The Kimball enterprise data warehouse bus architecture remains relevant because conformed dimensions coordinate meaning across business-process models while allowing incremental delivery. Inmon’s Corporate Information Factory emphasised an integrated enterprise foundation surrounded by related analytical components. Modern programmes can draw on both ideas without reproducing either historical technology stack exactly.
Enterprise integration, domain ownership, reusable data products, dimensional serving, and iterative delivery address different concerns. Treating them as competing product choices loses useful design options.
How Microsoft Fabric Changes the Physical Picture
Fabric is a useful example of why older category boundaries need care. Microsoft’s current Warehouse and Lakehouse decision guide describes both as enterprise analytical stores using open standard formats, but with different development and workload experiences.
The Fabric Warehouse supplies a T-SQL-oriented relational experience with data definition, data modification, transactions, stored procedures, and warehouse-oriented serving. The Lakehouse supplies file and table organisation with Spark-based engineering plus a system-generated, read-only SQL analytics endpoint over its Delta tables.
Both store tables in OneLake. Microsoft’s current OneLake documentation describes shared Delta Parquet storage, multiple analytical engines, shortcuts to internal and external data, and interoperability between Delta and Iceberg metadata. Shared storage can reduce copies between compatible workloads, but Warehouse and Lakehouse still expose different authoring, transaction, SQL, and operating behaviours.
The current Fabric medallion guidance describes bronze, silver, and gold as increasing levels of refinement and allows lakehouse-only or combined lakehouse-and-warehouse implementations. This is a product-specific example of a broader principle: logical layers don’t require one physical technology.
Power BI semantic models remain a separate responsibility. Microsoft’s semantic-model documentation describes business-friendly terminology, metrics, and analytical representation over warehouse or lakehouse data. Direct Lake can change how data is accessed, but it doesn’t eliminate the model’s measures, relationships, security, and user-facing meaning.
Avoid Architecture Shortcuts
Claims that need a second question
“One copy of the data”
Which transformations, caches, extracts, semantic storage, exports, and recovery copies still exist?
“Open architecture”
Which formats are open, and which code, metadata, security, operations, or APIs remain provider-specific?
“Schema on read”
Who establishes meaning, quality, and compatibility before critical consumers use the data?
“All workloads on one platform”
How are capacity, isolation, priority, specialist engines, and failure impact managed?
“Real-time analytics”
Which event boundary, processing delay, consistency, history, and decision actually require low latency?
“Self-service data”
Which governed products, semantic definitions, ownership, support, and access controls make service safe?
These phrases can describe genuine benefits. The follow-up question turns the benefit into a boundary that can be designed and tested.
Write the Architecture as Responsibilities
An architecture decision becomes clearer when it can be expressed without relying on a product diagram.
Architecture statement template
We will retain [which data] in [which governed form] so that [which workloads] can use it through [which processing and serving paths]. Integration and business meaning will be established in [which layer or product]. The design will meet [freshness, security, interoperability, performance, recovery, and cost boundaries] and will be owned by [named roles].
For example, an organisation might retain immutable source extracts and event data as governed open tables, use distributed processing for preparation, publish conformed dimensional models through a SQL warehouse, and expose certified semantic models to business users. That is a coherent combined architecture if its boundaries, copies, security, lineage, and ownership are explicit.
Another organisation with moderate volumes, structured sources, SQL skills, and business-intelligence workloads may need only a warehouse, staging area, and semantic layer. Adding a lakehouse would create responsibility without enough benefit.
The Complete Decision Trail
Across this series, the architecture has emerged from a sequence of decisions rather than a product category:
- 1Purpose: Identify the decisions, evidence, and integration problems that justify an analytical platform.
- 2Scope: Agree ownership, requirements, delivery boundaries, and an incremental route to value.
- 3Responsibilities: Separate ingestion, landing, integration, warehouse, semantic, and consumption concerns.
- 4Model: Select the business process, declare the grain, and design facts and descriptive context.
- 5History: Decide which changes overwrite, create versions, correct history, or restate results.
- 6Data movement: Capture changes, transform meaning, recover safely, and reconcile published outcomes.
- 7Operations: Set service objectives and design performance, monitoring, security, recovery, and change.
- 8Architecture: Allocate those requirements to storage, processing, modelling, and serving capabilities.
The final platform may be called a warehouse, lakehouse, data platform, or a combination. Its quality depends less on the label than on whether these decisions remain visible, testable, governed, and connected to the outcomes that justified the work.
Architecture selection is therefore not the end of the reasoning. It is the point at which the reasoning becomes a set of technical responsibilities the organisation must deliver and continue to own.