In Short: Three Layers, Each With One Job
Medallion architecture is the layering convention that modern lakehouses, Fabric's included, have settled on. Bronze stores data exactly as it arrived, an auditable landing zone. Silver stores it cleaned, deduplicated and conformed, the single place quality problems get fixed. Gold stores it shaped for consumption: star schemas, aggregates, feature tables. Data flows one way, and each layer answers a different question - what arrived, what is true, what the business consumes.
The convention is simple; estates still make a mess of it. This guide is the version we implement, in Fabric terms, with the failure modes named.
What Each Layer Is Actually For
Bronze: preserve. Raw structures, source timestamps, load metadata, nothing else. Its value is reprocessability: when silver logic changes (it will), you rebuild from bronze instead of begging source systems for history they may not keep. Arrivals come from pipelines, mirroring or shortcuts; the discipline is that nobody consumes bronze except silver jobs.
Silver: standardise. Typed columns, resolved duplicates, conformed keys, validated business rules - applied once, for everyone. This is where data quality work lives, so that no downstream consumer ever re-implements the same cleaning differently.
Gold: serve. Dimensional models for BI, aggregates for dashboards, feature tables for machine learning. Gold tables exist because a consumer needs them, each with an owner. In Fabric, gold is what semantic models read through Direct Lake, which makes gold design and semantic model quality two halves of the same discipline.
Laying It Out in Fabric
The mechanics are flexible; the boundaries must not be.
- Items: bronze and silver suit lakehouses (Spark transformations, tolerant of files); gold suits a warehouse for SQL-first teams or a gold lakehouse for Spark-first ones
- Workspaces: one workspace per layer keeps permissions honest (few people need bronze); larger estates go one medallion per domain instead
- Naming: make the layer visible in workspace and item names; archaeology is not a governance strategy
- Movement: notebooks or pipelines promote data between layers on a schedule or trigger; cross-layer reads happen through explicit interfaces, not casual queries into someone else's bronze
All three layers are Delta tables in OneLake, so no layer transition ever needs an export - the copies that remain are deliberate, one per layer, each earning its storage.
The Mistakes That Turn Medallion Into Mud
- Consuming bronze directly - the moment a report reads raw data, every source quirk becomes a production dependency
- Business logic in silver - silver conforms; it does not decide what "active customer" means. Contested definitions belong in gold where owners can be named
- Gold sprawl - a gold table per stakeholder request, none retired, until nobody knows which margin is real; endorsement and ownership fix this
- Skipping bronze to save storage - lake storage is the cheapest line on the bill; re-extraction is the expensive one
- Layers in name only - one workspace, one lakehouse, folders called bronze/silver/gold and permissions that let anyone write anywhere. The convention only pays when the boundaries are enforced
Get the boundaries right and the architecture fades into the background, which is the point: unglamorous layers underneath, trustworthy numbers on top.
Sources and Further Reading
Frequently asked
A layering convention for lakehouses: bronze holds raw data as it arrived, silver holds cleaned and conformed data, and gold holds business-ready models shaped for consumption. Each layer has one job, and data flows one way through them.
Because one-step transformations couple every downstream asset to every upstream quirk. Layers isolate concerns: bronze preserves an auditable copy of what actually arrived, silver fixes quality once for everyone, and gold shapes for each consumption need without re-cleaning.
A common pattern: bronze and silver in lakehouses (Spark-friendly, file-tolerant), gold in a warehouse or a gold lakehouse serving semantic models via Direct Lake. One workspace per layer or per domain both work; what matters is that the boundaries are explicit and enforced.
The concerns always exist - preservation, cleaning, shaping - but small estates can collapse layers physically while keeping them logically separate. What we advise against is skipping bronze: reprocessing history without a raw layer means re-extracting from sources that may no longer have it.
Neither: it is a platform-neutral convention that both platforms embraced. The same design works in Azure Databricks over Delta Lake, which makes medallion knowledge portable across the two.
