Medallion Architecture Explained: Bronze, Silver and Gold Layers

The pattern itself is sound — the most useful organising idea in lakehouse engineering, and it survives contact with real estates better than most things consultants draw. What goes wrong is that teams adopt the diagram without adopting the rules, and the rules are the whole point. A layer is not a folder. It is a promise about what a consumer of that data can assume.

This is the definitional version: what each layer is for, what does not belong in it, whether you need all three, and how it is built in Microsoft Fabric and Databricks.

Medallion architecture is a data design pattern that organises a lakehouse into three layers of progressively higher quality and readiness. Bronze holds data landed exactly as received and never edited. Silver holds cleaned, conformed, deduplicated records with business entities resolved. Gold holds business-ready aggregates and dimensional models built for reporting. Databricks, which named the pattern, states plainly that following it is a recommended practice, not a requirement.

The value is not the three-way split. It is that each layer carries a contract: anything in Bronze is what the source system actually sent, and can be replayed; anything in Silver can be joined on a business key without further cleaning; anything in Gold can be put in front of a Business Head without a caveat. Platforms fail because one of those three contracts was quietly broken, not because the diagram was wrong.

Three boundary rules are the ones teams break first. Bronze is immutable — a corrected record lands as a new Bronze row with a later load timestamp; edit it and you lose the ability to prove what the source said on a given date. Silver is conformed, not curated — the test: if two departments would disagree about a transformation, it does not belong in Silver. Gold is authored, not accumulated — every Gold table needs a named owner and a stated question it answers, or it is a report someone left lying around.

No. Three layers are a default, not a rule. The three-layer default earns its keep when at least one of these is true: more than three or four source systems that disagree about master data; a regulatory, contractual or audit reason to prove what a source sent on a given date; extracts that are expensive, rate-limited or unrepeatable, so reprocessing must come from your own storage; or more than one team consuming the same cleaned data for different purposes.

If none hold — a single ERP, one finance team, monthly reporting — three layers add two sets of pipelines, tests and storage costs for a dataset that needed one. A 12-table finance mart carrying the full treatment because it was "the standard" takes eleven weeks instead of four, and nothing about the output is better. Where a fourth layer legitimately appears: a landing zone ahead of Bronze holding files in original format, or a serving layer after Gold — pre-aggregated tables for one consumption pattern. Calling it "Platinum" is harmless; what matters is that it is documented as derived from Gold and never becomes a second source of truth.

In Fabric, medallion layers are implemented as separate lakehouses — Microsoft recommends one lakehouse per layer in its own workspace for access control — or as schemas within a schema-enabled lakehouse. Three features do most of the work. Lakehouse schemas are generally available and enabled by default; tables are addressed as schema.table, schemas carry their own access control, and schema shortcuts map a schema onto Delta tables held elsewhere without moving data.

Materialized Lake Views let you declare a layer transformation as a CREATE MATERIALIZED LAKE VIEW statement with a data quality constraint — CONSTRAINT valid_sales CHECK (sales_amount > 0) ON MISMATCH DROP, where the alternative is FAIL. Fabric detects dependencies, orchestrates refresh order, and exposes constraint violation counts per stage, which turns "is Silver clean?" from an opinion into a number. And Delta Change Data Feed enables incremental Bronze-to-Silver processing — but it captures changes only from the point it is enabled and does not backfill, so enable it when you create the table, not when you need it.

In Databricks, medallion layers are Delta tables governed by Unity Catalog's three-level namespace — catalog, schema, table. Two layouts work: a catalog per environment with bronze/silver/gold schemas inside, or a catalog per layer with schemas by business domain. Pick one and write it down; mixing both is how you end up with prod_gold.finance.fact_sales and gold.prod_finance.fact_sales in the same estate. Lakeflow Declarative Pipelines (formerly Delta Live Tables) enforce quality with expectations:

A sensible allocation: warn at Bronze so ingestion never stops, drop at Silver so downstream consumers get clean rows, fail at Gold so a broken number never reaches a dashboard.

These are unglamorous, and they are the difference between a platform that stays legible at year three and one that does not:

• Layer in the container, not the table name — silver.sales_order_line, not silver_sales_order_line in a flat namespace, so access control can follow the layer
• Source system in every Bronze object — bronze.sap_vbap, bronze.d365_salesorderheader; the source name is the only thing stable when the business reorganises
• Entity-first names in Silver, fact-or-dimension names in Gold — silver.customer; gold.fact_sales_order, gold.dim_customer
• The same load metadata on every Bronze table — source system, source file identifier, load timestamp, and a batch identifier you can filter on to replay
• One environment boundary, enforced — separate workspaces or catalogs for dev, test and production; never a _test suffix inside a production container
• Retire, do not accumulate — every Gold table gets an owner and a review date; tables without either are deprecated on a schedule

Silver becomes a dumping ground — the most common failure. Because Silver has no crisp acceptance test, anything "sort of cleaned" lands there; three years in you have hundreds of Silver tables, half single-consumer transformations that belonged in Gold, and engineers start reading from Bronze again. Gold tables multiply until nobody knows which is authoritative — four tables that all compute revenue, none deprecated, and the monthly variance meeting becomes a reconciliation exercise. The fix is organisational — a named owner per Gold table with the authority to switch old ones off — not architectural.

Bronze that is not actually replayable — teams enable Change Data Feed after go-live, overwrite Bronze partitions on reload, or never capture the source file, so when a Silver transformation turns out wrong for eight months the reprocessing cost lands on the ERP nobody can hammer during month-end. Test replayability on a real table before you need it. Medallion does not create master data — Silver resolves entities only if a mapping exists. And it does not settle a disputed KPI definition — if operations and finance disagree on how on-time delivery is calculated, putting it in Gold moves the argument rather than ending it.

Four questions, answerable in an afternoon, that tell you more than a design workshop will:

• Take your three most-used reports and trace each number back to a physical table. How many distinct tables produce the same measure?
• Take one Bronze table. Can you reprocess the last 90 days from your own storage today, without touching the source? If not, what is missing — Change Data Feed, retained files, or load metadata?
• Count your Silver tables and their consumers. The ones with exactly one downstream consumer are Gold tables in the wrong place
• For every Gold table, name the owner. The ones you cannot name are causing the arguments

If question one returns more than one table per measure, your problem is Gold governance, not architecture. If question two fails, fix Bronze before building anything else on top of it. We build these on Microsoft Fabric, OneLake and Power BI — first value in six weeks, on a working slice.