Coauthor: Artur Vieira
Part one of a series on medallion architecture with Fabric Data Warehouse.
Medallion architecture is one of the most common patterns for organizing data in Microsoft Fabric, but successful implementations require a series of design decisions — from choosing the right architecture pattern to securing, governing, and optimizing your workloads.
In this five-part series, we'll walk through the practical choices that shape a modern medallion implementation in Fabric Data Warehouse (DW), sharing recommendations, tradeoffs, and real-world guidance along the way.
In this installment, we'll focus on the first and most important decision: choosing the right medallion pattern for your workload.
Why this matters
Most teams designing a medallion architecture in Microsoft Fabric start with the wrong question: "Should I use a Lakehouse or a Warehouse?" The better question is, "How much Spark do I actually need?" Your answer will shape everything from development workflows to security and long-term maintenance.
Quick level-set: medallion organizes data into three layers — Bronze (raw), Silver (enriched), and Gold (curated) — to progressively improve data quality and structure. That’s the whole definition you need. The interesting part is how you map those layers onto Fabric.
The key decision: Data Warehouse, Lakehouse, or both?
Fabric gives you two major analytics storage options on OneLake: Lakehouse and Data Warehouse. Because Fabric DW is an enterprise-scale SQL warehouse built on the open Delta Lake format in OneLake — combining a relational SQL engine with lake storage, so data is stored as Delta Parquet with ACID transactions and time travel — you don’t have to choose between “warehouse” and “lake.” You’re really choosing how much of the pipeline you run in T-SQL versus Spark.
That leads to two patterns worth recommending: an all-in-one or hybrid approach.
Pattern A: All-in-One Data Warehouse
Use Fabric DW for Bronze, Silver, and Gold, separated by schemas (for example Bronze.*, Silver.*, Gold.*) or by separate warehouses, with data flowing raw → curated entirely within the warehouse using T-SQL or Data Factory pipelines.
- Best when: most of your data is structured (or can be structured on load) and your team prefers SQL-centric development.
- Why it’s nice: one engine, one skill set, transactions and views for every hop.
Figure: Pattern A — All-in-One Data Warehouse: one warehouse, Bronze/Silver/Gold as schemas
Pattern B: Lakehouse + Warehouse Hybrid
Land raw data in a Lakehouse for Bronze (and optionally Silver), where you can use Spark for complex prep, then implement Gold in the Warehouse as the SQL serving layer for BI. This works seamlessly because OneLake underpins both — Silver or Gold data can be materialized to Delta tables and queried by the Warehouse’s SQL endpoint without copying.
- Best when: You have unstructured or semi-structured data, or need heavy data engineering in Python or Scala.
- Why it’s nice: The right engine for each layer — Spark for heavy prep, T-SQL for serving — with no data copying, since OneLake underpins both
Figure: Pattern B — Lakehouse + Warehouse Hybrid: raw/Bronze land in a Lakehouse, Gold is served from the Warehouse.
Which should you pick?
Here’s the rule I’d give a customer:
Rule of thumb: For most SQL-focused analytics teams, an all-in-one Fabric Data Warehouse is the pattern I’d recommend starting with. If you have a mix of unstructured data or need heavy data engineering, land and refine raw data in a Lakehouse, then serve the final Gold layer from the Warehouse.
Fabric’s architecture lets you evolve, so you’re not locked in: start all-in-warehouse and add a Lakehouse later when a new source needs Spark, or vice versa.
All-in-One DW | Lakehouse + DW Hybrid | |
Primary skill | T-SQL | Spark / Python + T-SQL |
Best for data | Structured / relational | Unstructured, semi-structured, streaming |
Bronze lives in | Warehouse staging tables | Lakehouse (raw files, delta tables or both) |
Gold lives in | Warehouse | Warehouse |
Pick it for | Simplicity, one engine | Flexibility, heavy engineering |
One layout rule, whichever pattern you choose
Keep layer separation clear. Microsoft recommends isolating layers into different workspaces, or at least different Fabric items, for better control and governance. The payoff is real: separate items give you finer security control — only data engineers touch Bronze while analysts see only Gold — and clearer isolation, so an accidental change in Gold can’t affect Bronze.
Figure: One item per layer: Bronze, Silver, and Gold sit in separate warehouses for finer security and clearer isolation.
Takeaway
Don’t frame this as “Warehouse vs. Lakehouse.” Frame it as “How much Spark do I need?” If your workloads are structured and SQL-first, choose an all-in-one DW. If they’re unstructured or engineering-heavy, choose a hybrid approach, with Gold always served from the Warehouse. As your implementation grows, consider separating Bronze, Silver, and Gold into distinct Fabric items or workspaces to simplify governance and security.
Ready to go deeper? Explore the Microsoft Fabric documentation for Data Warehouse and OneLake, then stay tuned for Part 2 of this series, where we'll walk through howBronze, Silver, and Gold layers are implemented in practice.
This post is part of our Medallion Architecture on Fabric Data Warehouse series:
- Choosing your medallion pattern in Fabric Data Warehouse
- Building the Bronze → Silver → Gold layers
- Fabric DW best practices for medallion architectures
- Securing and governing your layers
- Performance tuning your medallion pipeline
In the next post, we'll explore what Bronze, Silver, and Gold layers actually look like in Fabric Data Warehouse and how data moves between them.
Microsoft Employee
