Medallion Architecture in Microsoft Fabric: What Actually Goes in Bronze, Silver and Gold for a Mid-Market Team?
You have one Fabric lakehouse and a notebook that lands the ERP and CRM nightly. Asked whether it is "doing medallion properly", the answer is a folder called raw, forty Delta tables, and no rule about which a report may read.
The cost arrives with the first bad run: a date-parsing fix drops a week of invoices, the ERP has moved on, and there is nothing to rebuild from. Finance asks why last quarter's revenue changed, and nobody can say which rule moved.
Every reference diagram shows three layers; none says what goes in each for a team of two. This is that inventory.
Key Takeaways
Never skip bronze: exact source copies with load metadata let you replay a bad silver run after the source has moved on.
Silver is a contract before it is a table: grain, keys, null and freshness rules, one owner; tables once a second subject area needs them.
Gold is the only door: materialised star-schema tables are all that reports, Excel and data agents bind to.
What is medallion architecture in Microsoft Fabric, and what does it cost?
Medallion architecture in Microsoft Fabric organises a lakehouse's Delta tables into three layers: bronze holds exactly what each source sent, silver the cleaned, conformed tables carrying the business rules, and gold the star-schema tables semantic models read. Against a classic warehouse it saves storage and reconciliation, not compute: OneLake storage is billed at a few cents per gigabyte-month, so a full bronze copy is tens of dollars a month, and a shortcut lets gold read a silver table in place.
A SQL Server warehouse ran staging, ODS and warehouse as three copies on one licence, each reconciled by an ETL job. Fabric swaps those for cheap storage plus a capacity you must size: three hops burn more capacity units than one, which on a small F SKU shows up as throttling first and on the bill only at the next SKU up. A one-subject-area build usually starts on an F2 or F4; price it against the SQL Server licence it replaces. A gold Warehouse reads the silver lakehouse's SQL analytics endpoint only within one workspace; otherwise shortcut silver into a lakehouse beside it.
What goes in the bronze layer, and what breaks if you skip it?
Bronze holds exactly what each source sent, plus three load-metadata columns: a load timestamp, a batch id and a source system name. It is append-only, written only by the ingestion job, and nothing in it is cleaned, recast or deduplicated. Skip it and you cannot replay silver after a bad run, or prove what the source said on the day.
The Files section holds raw files and API responses, one folder per source and load date; Tables holds one Delta table per source table. Each load appends the rows changed since the last, plus a full snapshot at month-end; a source that only delivers full extracts keeps daily snapshots for ninety days and month-ends indefinitely.
Delta time travel is no substitute: VACUUM removes old versions after days, not years, and an auditor asking why March revenue moved needs the rows as they stood on each load date.
What goes in the silver layer, and what does it promise gold?
Silver holds one typed, deduplicated and conformed Delta table per business entity (customer, invoice line), each at a fixed grain with a declared business key, written by one silver job (Dataflow Gen2 or notebook). The business rules live here: which statuses count as shipped, which accounts are revenue, each signed off by a named owner (the finance manager, not the engineer). Silver promises gold a contract: stable columns, one row per key, null and freshness rules, no change without notice.
Typed means dates in a declared timezone and amounts as decimals, not floats; conformed means the CRM's customer and the ERP's debtor resolve to one key under a written match rule.
The contract, per table:
Grain: one row per invoice line, enforced by a key-count test in the load, because Delta will not.
Keys: business key columns named and constrained not null.
Nulls: which columns are guaranteed populated.
Freshness: loaded by a stated time each day, with a timestamp gold can check.
Silver holds current state; a customer's region as it stood on the invoice date is a gold decision, a type 2 dim_customer rebuilt from bronze's dated snapshots.
When the ERP adds a "partially shipped" status, the owner's rule decides whether it counts, and the dated change note answers why last quarter moved. A silver table serves an entity, not a report; one shaped for a dashboard is gold work wearing silver's name.
What goes in the gold layer, and why should reports bind only to it?
Gold holds star-schema tables per subject area: a fact table at one grain plus the dimensions it joins to, materialised as Delta tables by one gold job, never SQL views. It is the only layer a semantic model, Excel or a Fabric data agent should bind to, because only gold carries the signed-off rules in a shape a business user can query without a join to get wrong.
For sales that is fact_invoice_line ringed by dim_customer, dim_product and dim_date: integer keys, additive amounts only on this fact (AR and stock balances get their own snapshot-grain fact), and one dim_customer shared with finance, not one per mart. Our plain-English guide to the star schema covers the shape.
Materialised matters because Direct Lake reads Delta files, not views: a model table over an endpoint view falls back to DirectQuery (Direct Lake on SQL) or is not allowed (Direct Lake on OneLake). Which item holds gold is settled in our Lakehouse or Warehouse comparison.
A data agent pointed at silver will add invoice headers to invoice lines; Excel users connect to the gold endpoint only, because a SQL endpoint exposes every table in its lakehouse by default.
Does a mid-market team need all three layers, or is two enough?
For a twenty-source estate run by one or two people, two layers is a sound start: bronze plus gold. Skip silver's tables, never bronze, and never silver's contract: grain, key, rules and owner are written and the gold job enforces them. Silver earns tables the day a second subject area needs the same conformed customer.
Most "start simple" advice skips bronze instead, yet bronze is the cheap layer and silver the set of tables somebody must own. Without bronze, the lakehouse is only as recoverable as the source's history.
An import model on Power BI Pro is two layers in disguise: Power Query as cleaning, the model as gold, no bronze to replay from. Writing those rules as the silver contract is the first job in a Power BI to Fabric migration, before any model is re-pointed at Direct Lake.
How long does a first medallion build take in Fabric, and which decisions are hard to reverse?
Plan about twelve weeks for a first medallion build in Fabric, delivering one subject area end to end: a data engineer or strong analyst, a business owner one day a week for sign-off, and a Power BI developer for the last month. Four decisions are expensive to reverse once reports are live, so settle them in a design fortnight alongside the first bronze loads: bronze metadata columns, silver grain and business key, gold table names, and which item the Direct Lake model binds to.
Call it two weeks for bronze and design, eight to build and test silver then gold against bronze, and two to bind the model and parallel-run the old numbers: the same design, build, cut-over shape as our 90-day SQL Server to Fabric migration plan.
A grain moved from invoice to invoice line rewrites every fact, a business key swapped from CRM id to ERP id touches every table, a renamed gold table breaks every visual, changed bronze metadata columns mean re-stamping twenty sources, and a model re-pointed at another item means its connection rewritten outside the UI (a deployment rule or TMDL edit; Direct Lake on OneLake has no deployment-rule support yet) and every report re-tested. That design fortnight settles all four, and is the scope of a short Microsoft Fabric consulting engagement.
Topology you can defer. One item per layer in its own workspace gives a permission boundary (report builders see only gold) for three items to maintain. Layers as schemas in one lakehouse or Warehouse suit one owner, but anyone with read sees every layer unless you add table-level security. Split the day someone outside the data team gets access.
Medallion is three contracts, not three folders
Bronze is the contract with the source: keep what it sent, so you can replay and audit. Silver is the contract with the business: a rule, an owner, a grain, a key. Gold is the contract with every reader: one shape, one set of names, one door.
Three folders without contracts are the same forty tables, sorted. Write the contracts first; the layers follow.
