Medallion Architecture: Bronze, Silver and Gold

Medallion architecture is a way of organising a data platform into three layers, so that a number on a dashboard can always be traced back to the record it came from.

The idea is simple enough to explain in a sentence, which is why it gets implemented badly. Teams create three schemas named bronze, silver and gold, then write transformations that jump between them in whatever direction is convenient, and end up with the same tangle they had before with better naming.

The value is not in the layer names. It is in the constraint: data only moves forward, each layer has exactly one job, and nothing downstream reaches back past the layer above it.

Bronze: keep the mess

Bronze holds data as it arrived. Bad dates, inconsistent spellings, duplicate rows, whatever the source produced, plus when it was ingested and where it came from.

The instinct is to clean on the way in. Resist it. The moment you correct data during ingestion, you lose the ability to answer the question that eventually gets asked: was this number always wrong, or did we break it?

Bronze is append-only and cheap to store. It is the audit trail that makes everything above it defensible, and the layer people regret not having.

Silver: decide what things mean

Silver is where the real work happens, and where most of the consulting time goes.

One row per real entity, which requires deciding that four differently spelled records are the same customer. Types corrected and validated. Keys resolved across systems. Business rules applied: which date counts, whether a cancelled order is included, what happens to a refund.

These are business decisions, not technical ones. They have to be made by people who know the operation, written down, and then encoded once. The failure mode is each report making its own assumptions, which is how you end up with three revenue figures and an argument.

Silver is also where personal data gets handled deliberately: pseudonymised or hashed where the analysis does not need the identity, so downstream users work with a stable key rather than a name.

Gold: shape it for the question

Gold tables are built for what someone asks, not for how the data is stored. Revenue by month by segment. Customer lifetime value. Forecast input features. One table per question or family of questions, denormalised, fast to read.

Because gold is derived and rebuildable, it can be reshaped when the questions change without touching anything below it. That is the payoff for the discipline in the layers underneath.

What good looks like six months later

The test is not whether the layers exist. It is whether these things are true.

1. Any number on a dashboard can be traced to source records without asking the person who built it.
2. Two reports of the same measure agree, because both read the same silver definition.
3. A new question can be answered by adding a gold table, without re-ingesting anything.
4. When a source system changes, exactly one place needs updating.

If any of those fails, the layers are decoration.

The four ways it goes wrong

Having implemented and inherited a number of these, the failure modes are consistent.

1. Cleaning in bronze. The most common. It feels efficient and it destroys the audit trail, so the question of whether a number was always wrong becomes unanswerable.
2. Skipping silver. Gold tables built straight off raw data, each re-implementing the cleaning slightly differently, until no two reports agree and nobody can say which is right.
3. Gold tables that reach backwards. An aggregate that joins to a bronze table because silver was missing a field. This breaks the guarantee that made the layering worth having.
4. Definitions that live in people’s heads. The rules were agreed in a meeting and never written down, so the person who encoded them becomes a permanent dependency.

All four are cheap to avoid at the start and expensive to unwind later, which is the argument for spending the first week on definitions rather than on tables.

If you already have layers that are not working

A common starting point is an estate that already has bronze, silver and gold schemas and none of the guarantees, usually because transformations move in whatever direction was convenient.

That is fixable without starting again. The work is tracing what actually depends on what, identifying where the layering is violated, and rebuilding those paths in the right order. It is cheaper than a rewrite and it restores the property that made the design worth having.

What the engagement includes

• A definition workshop. The entity, date and inclusion decisions agreed with the people who know the operation, written down before any table is built.
• Bronze ingestion. Raw, append-only, preserved exactly as received with ingestion time and source recorded.
• Silver conformance. De-duplication, type correction, key resolution and business rules encoded once, with personal data handled deliberately.
• Gold tables per question. Aggregates shaped for what the business asks, rebuildable without touching the layers below.
• Lineage and documentation. What each table means, where it came from and how to extend it, so the architecture survives your team changing.

How the work runs

1. Agree definitions first. Entity, date and inclusion rules signed off by people who know the operation.
2. Land bronze untouched. Append-only, with ingestion metadata, cleaning nothing.
3. Build silver once. Conform, de-duplicate, resolve keys, encode the rules in one place.
4. Shape gold to questions. Denormalised aggregates per question family, rebuildable on demand.
5. Prove traceability. Pick numbers off a dashboard at random and trace them to source. That is the acceptance test.

Proof

An implementation of exactly these three layers, with the table counts and the governance, is described in the awards manufacturer case study.

Related

• Databricks Consulting
• Data Engineering
• Databricks Apps

Talk about your situation

The first conversation is short and mostly questions. Get in touch and tell me what you are trying to fix. Or see how this is priced.

Frequently Asked Questions (FAQs)

What is medallion architecture?

A three-layer design for a data platform. Bronze holds raw data exactly as ingested. Silver holds cleaned, de-duplicated, conformed data with business rules applied. Gold holds aggregates shaped for the questions the business asks. Transformations only move forward, which is what makes any number traceable to source.

Why is it called bronze, silver and gold?

The metals describe increasing refinement rather than importance. Bronze is raw and unrefined, silver is cleaned and conformed, gold is finished and ready to read. The naming is a convention popularised by Databricks and is now used broadly across lakehouse designs.

Do I need all three layers?

Yes, and skipping silver is the shortcut that costs most. Reports built straight off raw data each re-implement cleaning slightly differently, and within a year no two agree. Rebuilding at that point is more expensive than building silver properly at the start.

Is medallion architecture only for Databricks?

No. The pattern is platform-independent and works on any lakehouse or warehouse. Databricks popularised the naming and its tooling fits the pattern closely, particularly Unity Catalog for governance and lineage, which is why it is a common place to implement it.

How long does it take to implement?

It depends far more on how many source systems there are and how much disagreement exists about definitions than on the technical build. The definition workshop is often the longest part, and it is the part that determines whether the result holds up.

Where does personal data sit in this design?

It is classified before indexing and handled at the silver layer, where it is pseudonymised or hashed wherever the downstream analysis does not need the identity. Analysts then work with a stable key rather than a name, which keeps most analysis possible without spreading personal data through every gold table. Bronze retains the original under tighter access control.