Medallion architecture: bronze, silver and gold, and what it does not do

Also called: the multi-hop architecture, bronze/silver/gold layers, the lakehouse pattern

The default shape of a modern lakehouse pipeline, and the one that most often gets adopted in the belief that it answers a question it does not even ask.

What it is

Medallion splits a pipeline into three layers. Bronze holds everything exactly as it arrived, unmodified. Silver holds it cleaned, typed and deduplicated. Gold holds business-ready tables that people actually query.

It came out of the Databricks world and is now the house style of most lakehouse projects, Microsoft Fabric included. Its real virtue is that it makes the state of every table obvious from where it sits: nobody has to ask whether a given table has been cleaned yet.

And here is the part worth being direct about, because skipping it causes most of the disappointment: Medallion organises the work; it does not model the business. It tells you where a table sits in a pipeline. It does not tell you what a row means, what the grain is, or how history is kept. Those questions still have to be answered — in gold, usually by modelling it dimensionally.

How the tables are actually shaped

Bronze: prove what arrived

Bronze is a landing zone with a memory. Typically the source columns as they came, plus a few of its own:

Bronze_Customer
  ...every source column, as it arrived...
  _ingested_at    DATETIME2
  _source_system  NVARCHAR
  _batch_id       NVARCHAR
  _raw_hash       BINARY(32)   -- hash of the row EXACTLY as received

• Do not clean it, and do not normalise the hash input. No trimming, no upper-casing. The entire point of bronze is that it can prove what was received, and a hash computed over tidied-up input cannot.
• Duplicate business keys belong here, and so do rows with no key at all. Deduplicating is silver’s job.
• It is usually a heap with no keys and no indexes, loaded in bulk. There is no candidate key to declare, and an index would only slow the load.

Silver: one row per thing, with history

Silver reads bronze and nothing else. It types the columns properly, deduplicates on the business key — newest ingest wins, which is a real tie-break rather than an arbitrary one — and keeps history with validity dates.

That makes silver’s primary key the business key plus the moment the version started, not the business key alone. The same shape as an Inmon core, but on the source’s own key, because not inventing a surrogate is part of the point of this layer.

Rows with no business key stay in bronze. Nothing can key them, so nothing downstream could join them anyway — and quietly passing them along makes the counts wrong in a way nobody traces.

Gold: the layer that still needs a model

Gold reads silver, never bronze. It is aggregated, filtered to the current and valid rows, and shaped for a question. It is also where the modelling you skipped arrives: in practice most gold layers are star schemas, which means most Medallion projects are doing Kimball as well, not instead.

A gold table is usually better off with a clustered index than a primary key: it is rebuilt whole and grouped by period and by whatever it slices on, and a grouping column may legitimately be NULL — which a primary key would refuse.

When it fits, and when it does not

Medallion is easy to adopt and hard to regret, which is exactly why it is worth being clear about what it leaves undone.

Those two lists are Netune’s own judgement of this methodology, copied from the rule file it scores a real database with.

What it costs

The mistakes that are expensive

Cleaning bronze “just a little”

Trimming whitespace on the way in feels harmless and destroys the only thing bronze was for. The moment bronze differs from what was sent, it can no longer settle an argument with the source system — which is the situation you built it for.

Expecting gold to model itself

Teams adopt Medallion, build bronze and silver competently, and then discover that “gold” is not a design — it is an empty schema with a colour. The grain, the conformed dimensions and the history questions are all still waiting. Decide the gold model at the start; Medallion will not decide it for you.

Reading bronze from gold

It happens when something is missing from silver and a deadline is close, and it quietly removes every guarantee the middle layer was making. If gold needs something bronze has, the fix belongs in silver.

How it compares

Medallion or Kimball?

Not really a choice — they answer different questions. Medallion says where a table sits in the pipeline; Kimball says what a row means. The common and correct arrangement is Medallion for the pipeline with a star schema in gold.

Medallion or Data Vault?

Bronze and a raw vault overlap: both keep what arrived so it can be proven later. The vault also integrates across systems and keeps attribute-level history in a queryable structure, which bronze does not. On a lakehouse with several systems, people often run both — bronze for the raw files, a vault in silver.

Is Medallion the same as staging?

Bronze is a staging layer with one extra promise: it keeps what it received, unmodified, rather than being truncated and refilled each run. Everything else staging does — keeping the transformation off the production system, giving a failed load somewhere to restart — bronze does too.

Questions people ask