The Lakehouse Pattern in Microsoft Fabric: Medallion Architecture Explained
Microsoft Fabric Lakehouse medallion architecture explained. What goes in bronze, silver, gold layers — with a practical example, common mistakes, and DP-700 exam relevance.
What the medallion pattern actually is
The medallion pattern is a way of organising data inside a Lakehouse into three named tiers — bronze, silver, and gold — that progressively shape raw source data into something a report or model can rely on.
It's not a Microsoft invention; it predates Fabric by years. But Fabric's Lakehouse is opinionated enough about Delta tables, schemas, and shortcuts that the medallion pattern has become the de facto reference architecture there.
The names matter less than the discipline they enforce. The discipline is: never let a report touch raw data, and never let a transformation touch your final model. Three layers, three responsibilities.
Bronze — raw, append-only
The bronze layer is the landing zone. Data lands here in roughly the shape it had at the source, with one rule:
Bronze is append-only and immutable. You add records, you never edit them.
What that gets you:
- A reproducible audit trail. If a downstream calculation goes wrong, you can rebuild silver and gold from bronze.
- The ability to time-travel via Delta's transaction log — Delta tables in bronze keep their history.
- A single ingestion point per source. If three reports all need a feed from your CRM, that feed lands in bronze once, not three times.
What goes in bronze:
- Raw API extracts as-received
- CDC change feeds from operational databases
- Files from blob storage, SFTP drops, or webhooks
- Anything you'd consider "the source of truth" coming into the platform
What does NOT go in bronze:
- Cleaned data
- Joined data
- Anything you'd want a business user to read
Silver — cleaned, conformed, queryable
Silver is bronze with the obvious problems fixed:
- Type coercion (string "2026-01-15" becomes a real date)
- Null handling (decided per-column, not blanket)
- Deduplication (often via SCD-style logic on a natural key)
- Light joining where it materially helps consumers (e.g., resolving a user_id to a username)
- Schema enforcement (Delta makes this enforced rather than optional)
Silver tables are what an analytics engineer actually queries. You can write SQL against silver and get sensible answers without learning the source system's quirks.
The trap most teams fall into: silver becomes "a slightly-cleaned version of bronze with a different name". That's not silver. Silver should be conformed — the same business concept (customer, order, product) has one canonical schema in silver regardless of how many sources contributed to it.
Gold — model-ready, often denormalised
Gold is the layer your semantic models, reports, and ML features point at. It's purpose-built for consumption.
Practically, gold often looks like:
- Star-schema fact and dimension tables for BI
- Pre-aggregated rollups for performance-critical dashboards
- Feature tables for ML
- Wide denormalised tables when downstream consumers want simplicity over normalisation
Gold tables can have business logic baked in — calculated columns, derived measures, segmentations. The reason that's safe in gold (and unsafe in silver) is that gold tables are scoped to specific consumers. If marketing's gold table has a "high-value customer" flag with marketing's definition, finance's gold table can have a different "high-value customer" flag with finance's definition. They're allowed to disagree because they serve different audiences.
A worked example — sales reporting
To make this concrete:
Bronze tables:
- raw_orders_csv (daily file drop)
- raw_customers_api (hourly extract)
- raw_products_changefeed (CDC stream)
Silver tables:
- orders (cleaned types, dedup'd, customer_id resolved)
- customers (cleaned types, slowly-changing dimension applied)
- products (cleaned types, latest version per product_id)
Gold tables:
- fact_sales (one row per order line, with customer/product foreign keys)
- dim_customer (star-schema customer dimension)
- dim_product (star-schema product dimension)
- agg_sales_monthly (pre-aggregated for the executive dashboard)
The semantic model points at gold. Reports point at the semantic model. Nobody — neither analysts nor reports nor models — touches silver or bronze directly.
How to actually implement this in Fabric
The Fabric-native way:
- Create one Lakehouse per layer in the same workspace (lh_bronze, lh_silver, lh_gold).
- Or create one Lakehouse and use schemas (Lakehouse schemas are now GA) to namespace bronze, silver, gold within it.
- Use shortcuts so silver can read from bronze without copying data, and gold can read from silver without copying.
- Pipelines orchestrate the bronze → silver → gold movement, typically with notebook activities for non-trivial transformations.
- The semantic model points at gold tables in Direct Lake mode — fast, current, no refresh schedule.
The shortcut model is what makes the layer separation lightweight: data physically lives once, but logically appears in each layer's namespace.
Common mistakes
Putting transformations in bronze. The instant you write a transformation into bronze, you've lost the audit trail. Bronze is append-only, full stop.
Skipping silver. Some teams go bronze → gold directly, justified as "we're agile". This works for one report. It collapses when the second report needs the same cleaned data and now there are two definitions of "customer".
Treating gold as a single table. Gold is plural by design. Different consumers get different gold tables, even when those tables share underlying silver sources.
Putting business logic in silver. Silver is conformed, not opinionated. A "high-value customer" flag goes in gold, not silver.
Why this matters for DP-700
The Fabric Data Engineer (DP-700) exam tests medallion architecture explicitly. Expect questions on:
- Which layer should hold deduplication logic? (silver)
- Where do calculated columns belong? (gold)
- What enforces schema in a bronze Delta table? (the Delta table itself)
- How would you let three downstream Lakehouses share the same silver layer without copies? (shortcuts)
Understanding the discipline behind the layer names is the difference between memorising answers and reasoning to them.
The medallion pattern is the smallest architecture that scales. Use the names if it helps your team communicate. Use the discipline either way.
Frequently asked questions
What is the medallion architecture in Microsoft Fabric?
The medallion architecture organises data in a Microsoft Fabric Lakehouse into three named layers — bronze (raw, append-only), silver (cleaned and conformed), and gold (model-ready, often denormalised). Each layer has a defined responsibility: bronze captures source data verbatim, silver fixes typing and deduplication and produces canonical schemas, and gold is purpose-built for the semantic models and reports that consume it.
What goes in the bronze layer of a Lakehouse?
Bronze holds raw source data in roughly the shape it had at origin — API extracts as-received, CDC change feeds from operational databases, files from blob storage or SFTP drops, webhooks. Bronze is append-only and immutable: you add records, you never edit them. This preserves the audit trail and lets you rebuild silver and gold from scratch if a downstream transformation goes wrong.
Should gold tables be normalised or denormalised?
Gold tables are typically denormalised because they're built for specific consumers — semantic models, dashboards, ML features. Star schemas (fact and dimension tables) and wide aggregated tables are common. Different consumers can have different gold tables drawing from the same silver, with consumer-specific business logic baked in.
Can I use one Lakehouse for all three medallion layers?
Yes. You can use one Lakehouse with schemas to namespace bronze, silver, and gold (Lakehouse schemas are now generally available in Fabric), or you can use three separate Lakehouses. The choice is mostly a governance preference — separate Lakehouses make permissions easier to manage at the layer level; a single Lakehouse with schemas is easier to administer if access is uniform.
Is medallion architecture covered in the DP-700 exam?
Yes — DP-700 (Microsoft Fabric Data Engineer Associate) tests medallion architecture explicitly. Expect questions on which layer holds deduplication logic, where calculated columns belong, how schema is enforced in a bronze Delta table, and how shortcuts let multiple downstream Lakehouses share a silver layer without copying data.
