Medallion Architecture in Microsoft Fabric: Bronze, Silver, Gold
Medallion architecture in Microsoft Fabric means three lakehouses (or two lakehouses and a warehouse) in OneLake: bronze holds raw data exactly as it arrived, silver holds cleaned and deduplicated tables, and gold holds the star schema your Power BI reports read. Microsoft's medallion architecture guidance calls it the recommended design approach for Fabric, and its advice as of August 2026 is one item per layer, each in its own workspace, with Delta tables in silver and gold.
What each layer is for
| Layer | What it holds | Who touches it | Format |
|---|---|---|---|
| Bronze | Raw copies of source data, unchanged, plus load metadata | Pipelines and notebooks only | Source format (JSON, CSV, Parquet) or Delta |
| Silver | Cleaned, typed, deduplicated tables, still one table per source entity | Data engineers, data scientists | Delta |
| Gold | Facts, dimensions, aggregates shaped for reporting | Analysts, Power BI, SQL tools | Delta |
Bronze: land it and leave it
Bronze stores everything as it arrives. No type casting, no filtering, no renaming. Add a few columns (load timestamp, source file name, batch ID) and stop there.
The point is replayability. When you discover a silver transformation was wrong three months ago, you rebuild silver from bronze. Without bronze you go back to the source system, and a CRM or ERP will not give you last quarter's state of a record.
Microsoft's advice for bronze is to keep the original format where possible. If the source is a relational database, land it as Delta tables. If the data already sits in ADLS Gen2, Amazon S3, Google Cloud Storage, or another OneLake location, do not copy it: create a OneLake shortcut in the bronze lakehouse and read it in place.
Silver: fix it, do not model it
Silver does the boring work Microsoft's own e-commerce example describes: standardize date formats across sources, convert currencies to one unit, drop test transactions, match the same customer across systems. Tables are still source-shaped. A Shopify orders table and a Zoho CRM deals table stay separate; they just become trustworthy.
Typical silver rules:
- Enforce a schema and data types.
- Deduplicate on a business key.
- Apply slowly changing dimension logic where history matters.
- Conform keys (one customer ID format, one product code format).
- Quarantine rows that fail validation instead of silently dropping them.
Gold: shape it for the question
Gold is where you join silver tables into a star schema: a sales fact, a customer dimension, a date dimension, plus pre-aggregated tables for dashboards that need sub-second response. Gold tables are built per business domain or per report family, and it is normal to have more than one gold table derived from the same silver data.
Gold is the only layer business users and Power BI should read. Microsoft is explicit that bronze tables should not be served directly to the SQL analytics endpoint or Direct Lake.
Lakehouse or warehouse for each layer
Microsoft documents two patterns:
| Pattern | Bronze | Silver | Gold | Business users query via |
|---|---|---|---|---|
| 1 | Lakehouse | Lakehouse | Lakehouse | SQL analytics endpoint |
| 2 | Lakehouse | Lakehouse | Warehouse | Warehouse endpoint |
Bronze and silver are lakehouses in both patterns because lakehouses take files as well as tables, accept shortcuts, and are written by Spark. The only decision is gold.
Pick a lakehouse for gold when your team writes Spark or Python, your transformations are notebook-based, and you want one engine end to end. The SQL analytics endpoint gives analysts read-only T-SQL (views and table-valued functions, no INSERT or UPDATE).
Pick a warehouse for gold when your team is T-SQL first, you want stored procedures and full DML, or you need multi-table transactions. Microsoft's lakehouse vs warehouse decision guide sums it up: Spark means lakehouse, T-SQL means warehouse, multi-table transactions means warehouse. A warehouse also handles its own file compaction and enables V-Order by default, so gold maintenance is mostly done for you.
Either way the data is Delta in OneLake, so Power BI Direct Lake works on both. If you are still weighing the two, the detailed comparison is in Lakehouse vs Warehouse in Microsoft Fabric.
Workspace layout
Microsoft recommends each layer in its own workspace rather than three lakehouses in one workspace. Three reasons:
- Access control. Workspace roles are the coarsest and most reliable permission boundary in Fabric. Analysts get Viewer on the gold workspace and nothing on bronze.
- Capacity separation. Each workspace is assigned to a capacity. You can put heavy bronze and silver ingestion on one capacity and keep the gold workspace on another so report users do not feel the ETL load. How capacities are priced is covered in Microsoft Fabric pricing explained.
- Deployment pipelines. Dev, test, and prod promotion works at the workspace level.
A naming convention that scales:
Sales-Bronze,Sales-Silver,Sales-Gold(workspaces)lh_bronze,lh_silver,lh_goldorwh_gold(items inside)
If you run several business domains (sales, finance, operations), Fabric domains group the workspaces so each domain owns its own three layers. That is the data mesh pattern Microsoft describes, and it fits companies where finance and sales teams will not share one backlog.
Small teams sometimes start with one workspace and three lakehouses to reduce overhead. That works for a pilot. Split before you give business users access, because moving items between workspaces later means rewiring every pipeline and shortcut.
How data moves between layers
You have four tool choices, and most real builds mix them:
| Tool | Best for | Layer it usually serves |
|---|---|---|
| Data pipelines (Copy activity) | Pulling from built-in connectors (databases, SaaS apps, cloud storage, REST) into bronze on a schedule | Source to bronze |
| Notebooks (Spark, PySpark, Spark SQL) | Complex cleaning, merges, SCD logic | Bronze to silver, silver to gold |
| Dataflows Gen2 | Low-code transforms by analysts | Silver to gold for small models |
| Materialized lake views | Declarative SQL transforms with automatic refresh ordering | Bronze to silver to gold |
Materialized lake views deserve attention if you are starting fresh. You define each silver and gold table as a CREATE MATERIALIZED LAKE VIEW statement in Spark SQL. Fabric works out the dependency order, picks incremental, full, or skip refresh per view, and lets you declare data quality rules inline, for example CONSTRAINT valid_sales CHECK (sales_amount > 0) ON MISMATCH DROP. Incremental refresh needs Change Data Feed enabled on the source tables. PySpark authoring is in preview as of August 2026 and only does full refreshes. For ML inference or API calls you still need notebooks.
Orchestrate the whole flow with one pipeline: Copy activity into bronze, notebook activities for silver and gold, then a Lakehouse Maintenance activity (OPTIMIZE and VACUUM) and a Refresh SQL Endpoint activity so the gold endpoint sees new tables before reports refresh.
Settings that differ by layer
This is where most self-built Fabric setups go wrong: the same Spark defaults applied to all three layers. Microsoft's table maintenance guidance publishes different targets per layer.
| Setting | Bronze | Silver | Gold |
|---|---|---|---|
| Optimization priority | Ingestion speed | Balance | Read speed |
| Target file size | Small files acceptable | 128 to 256 MB | 400 MB to 1 GB |
| V-Order | Off (adds 15 to 33% write overhead) | Optional | On (40 to 60% faster cold-cache Direct Lake queries) |
| Liquid Clustering | No | Yes | Yes |
| Optimize-write | On | On | On |
| Auto-compaction | Optional | On | On |
| Scheduled OPTIMIZE | Optional | Frequent | Frequent |
| Partitioning | Allowed, discouraged for new builds | Use Liquid Clustering instead | Use Liquid Clustering instead |
Three things to know:
- V-Order is off by default in new workspaces. If gold feeds Direct Lake, turn it on at the table level with
delta.parquet.vorder.enabled = trueso every writer respects it, not just your session. - Set properties on the table, not the session. Session configs vanish when a different notebook writes the same table. Table properties (
delta.autoOptimize.optimizeWrite,delta.autoOptimize.autoCompact,delta.parquet.vorder.enabled) persist. - VACUUM keeps seven days by default. That is your time-travel window. Shorten it only on bronze tables you never roll back, and keep it on silver and gold.
For gold tables read by Direct Lake, Microsoft's target is row groups of 8 million or more rows. For gold tables read mainly through the SQL analytics endpoint, 400 MB files with about 2 million rows per row group.
A worked example: retail company on Fabric
Sources: Shopify (orders, customers, products), Zoho CRM (B2B deals), a 3PL warehouse system exporting CSV inventory snapshots, and QuickBooks.
Bronze workspace. One pipeline runs hourly. Copy activities land Shopify and Zoho API responses as JSON in the Files area, then a notebook appends them to Delta tables with _ingested_at and _source_file columns. The 3PL CSVs sit in an S3 bucket, so a shortcut points at the bucket rather than copying. QuickBooks lands daily.
Silver workspace. Notebooks cast types, deduplicate Shopify orders on order_id keeping the latest updated_at, match Zoho accounts to Shopify customers on normalized email, convert every currency column to USD at the day's rate, and write one Delta table per entity with Liquid Clustering on the most filtered column (usually a date). Rows failing validation go to a quarantine schema with the failure reason.
Gold workspace. A warehouse, because the finance team writes T-SQL. Stored procedures build fact_sales, fact_inventory_snapshot, dim_customer, dim_product, and dim_date, plus a daily_sales_summary aggregate for the executive dashboard. Power BI connects in Direct Lake mode. Analysts get Viewer on this workspace only.
Total items: three workspaces, two lakehouses, one warehouse, one orchestration pipeline, four notebooks, one semantic model. That is the whole platform for a mid-sized business. The broader component map is in Microsoft Fabric architecture explained.
Mistakes that cost time later
- Transforming in bronze. The moment you cast a type or drop a column on the way in, you have lost the raw record.
- Letting Power BI read silver. It works on day one and becomes an unmanageable dependency by month six. Build the gold table.
- One gold table for everything. Microsoft's own guidance says multiple copies optimized for different consumers are fine. Storage is cheap relative to compute.
- Skipping OPTIMIZE. Hourly Spark writes produce thousands of small files. Direct Lake performance falls off a cliff, and nobody connects the slow dashboard to the missing maintenance job.
- No SQL endpoint refresh step. New gold tables written by Spark can lag in the SQL analytics endpoint. Add the Refresh SQL Endpoint activity at the end of the pipeline.
FAQ
Do I need three separate lakehouses for medallion architecture in Fabric?
Microsoft recommends one lakehouse (or warehouse) per layer, each in its own workspace. You can technically run all three layers in one lakehouse using schemas, but you lose per-layer access control and capacity separation.
Should the gold layer be a lakehouse or a warehouse?
Use a lakehouse if your team writes Spark or wants Direct Lake with the fewest moving parts. Use a warehouse if your team is T-SQL first or you need multi-table transactions and stored procedures. Both store Delta tables in OneLake, so Power BI works with either.
Is silver one table per source table or a merged model?
Silver is usually still source-shaped: one cleaned, deduplicated, typed table per source entity, with conformed keys and formats. Joining into facts and dimensions happens in gold.
Do I need to copy data into bronze if it already lives in ADLS Gen2 or S3?
No. Create a OneLake shortcut in the bronze lakehouse pointing at the existing storage. Fabric reads it in place, and Microsoft's guidance is to shortcut rather than copy whenever the source is OneLake, ADLS Gen2, Amazon S3, or Google Cloud Storage.
Can I skip bronze and load straight into silver?
You can, but you lose the ability to reprocess. Bronze is your replay buffer: when a silver rule is wrong, you rebuild from bronze instead of re-extracting from the source system.
Where Maxwize fits
Maxwize designs and builds Fabric lakehouses for small and mid-sized businesses, including the Shopify and Zoho CRM ingestion patterns above, with data analytics projects typically ranging from $1,000 to $20,000 depending on source count and model complexity. If you want a medallion setup that your own team can run afterwards, see our Microsoft Fabric services or get in touch.