Decision guide Microsoft Fabric
Lakehouse vs Warehouse Decision Guide
Seven questions for choosing between a Fabric Lakehouse and a Warehouse based on who writes the data, who reads it and how it is operated.
- Type
- Decision guide
- Level
- Intermediate
- Format
- Printable
In short
Neither item is better in general. Choose by workload: who writes the data and in which language, who queries it, whether you need files, and how you deploy and maintain it. Many platforms use both, each for a clear job.
Who it is for
- Engineers and architects designing a Fabric platform
- Teams deciding where their Gold or serving layer should live
What it helps you do
- Compare the two items on the dimensions that matter for your workload
- Answer the decision questions for one specific dataset
- Avoid keeping the same data in both without a reason
On this page
At a glance
Lakehouse
Engineering-first
- Spark and notebooks
- Files and Delta tables side by side
- Engineering workflows
- Flexible processing
- Python and PySpark
Read with T-SQL through the SQL analytics endpoint (read-only).
Warehouse
SQL-first
- T-SQL reads and writes
- Relational serving
- T-SQL workflows: procedures, transactions
- Reporting
- Familiar to analysts and SQL developers
Table maintenance is handled by the service.
Decision questions
Answer these for one dataset or layer at a time, not for the whole platform.
| Question | Leans Lakehouse when… | Leans Warehouse when… |
|---|---|---|
| Who writes the data? | Data engineers with notebooks or Spark jobs | SQL developers with T-SQL, procedures or dbt on SQL |
| Who queries it? | Engineers, data scientists, Spark jobs | Analysts, reports and applications using T-SQL |
| Is Spark central? | Yes: transformations, ML or Python libraries | No, or only upstream |
| Is T-SQL central? | Only for reading | Yes, including writes and multi-table transactions |
| Is the data mainly engineering or serving? | Engineering: landing, cleaning, conforming | Serving: modelled tables for reports and APIs |
| Do you need file-level access? | Yes: raw files, semi-structured data, shortcuts | No, tables are enough |
| What are the deployment and maintenance needs? | Team can schedule OPTIMIZE / VACUUM and deploy notebooks | Team prefers managed maintenance and SQL database projects |
If the answers split, that is normal: a common pattern is Lakehouses for landing and cleaning, and a Warehouse for a serving layer that SQL developers own.
Before you decide
- Test with your real data volumes and query patterns; small tests can mislead in both directions.
- Check which security model your readers need, and through which engine they will query.
- Decide who owns table maintenance, schema changes and deployment for each item.
- Avoid copying the same tables into both items only to use both engines; shortcuts and the SQL analytics endpoint often remove the need.
For the full comparison and the reasoning behind each question, follow the related articles below, or the Microsoft Fabric learning path.
Go deeper: related articles
Microsoft Fabric
Designing a Scalable Microsoft Fabric Architecture
A practical guide to workload boundaries, storage, capacity, deployment and operations in Microsoft Fabric.
Microsoft Fabric
Medallion Architecture Explained: Bronze, Silver and Gold
What the Bronze, Silver and Gold layers are for, how data quality and incremental processing work across them in Microsoft Fabric, and when fewer layers are the better design.
Cloud & Automation
Report Engine Architecture: Request to Result
Trace a report request through gateway, security, validation, cache, Fabric query, result construction and monitoring.
Cloud & Automation
What Is a Report Engine?
Define the report engine as a secure service between UI or API consumers and analytical data.
Planned articles on these topics
Build it: related projects
Fabric Data Platform Template
A reusable end-to-end Microsoft Fabric reference implementation: ingestion, Bronze, Silver and Gold layers, serving, Git, CI/CD and observability, built with practical engineering patterns.
Modern Report Engine
A planned reference implementation for secure, tenant-aware analytical requests, cache decisions, Fabric queries, exports and operational monitoring.
Related talks
Designing Microsoft Fabric for Scale
The architecture decisions that decide whether a Fabric platform stays manageable as data, teams and workloads grow: workload boundaries, Lakehouse vs Warehouse, Medallion layers, capacity, Git and observability.
Formats: Talk · Webinar · Workshop · Internal session
Medallion Architecture Without Over-Engineering
Bronze, Silver and Gold as responsibilities rather than mandatory boxes: when all three layers help, when fewer are better, and how Delta, incremental processing, file design and data quality fit in.
Formats: Talk · Webinar · Workshop · Internal session