Medallion architecture is a way of organising data in a lakehouse into three layers of increasing quality. Bronze holds raw data exactly as it arrived. Silver holds cleaned, validated and joined data. Gold holds tables shaped for a specific business use, such as a report or a model. Data flows one way, from bronze to gold, and each layer has a clear job.
What is medallion architecture?
The name was popularised by Databricks, but the idea is older than the label and works on any modern platform, Snowflake and Microsoft Fabric included. It's a naming convention for something good data teams were already doing: separating what arrived from what you trust from what you publish.
| Layer | Holds | Who uses it | Rule |
|---|---|---|---|
| Bronze | Raw data, as received, with load time and source | Engineers | Never edit it. Append only. |
| Silver | Cleaned, deduplicated, typed, conformed data | Engineers, analysts, data scientists | One trusted version of each entity |
| Gold | Aggregates and models for a business purpose | Analysts, BI tools, applications | Built for the question being asked |
Bronze: keep everything, change nothing
Bronze is a record of what the source systems sent you. Not what they should have sent. The duplicates, the nulls, the badly formatted dates all stay.
That feels wrong the first time. Why store rubbish? Because the day a silver rule turns out to be mistaken, bronze is the only thing that lets you rebuild correctly without going back to a source that may have overwritten its history.
Add a little metadata on the way in: when each record was loaded, from which file or system. Otherwise leave it alone. The one exception is data you aren't allowed to hold raw, such as card numbers, which should be masked before it lands. That's the case for a small ETL step in front of the lakehouse.
Silver: where the real work is
Silver is where data becomes trustworthy, and it's where most of the engineering effort belongs. Types are fixed. Bad records are rejected or quarantined. Duplicates are resolved. Customer codes from three systems are mapped to one.
A good silver layer answers a plain question: what is a customer, an order, a claim, according to this company? One table per entity, documented, tested on every run.
The hardest part is usually identity. The same person appears in the CRM, in billing and in support under slightly different names, and silver is where that has to be sorted out. It's a discipline of its own, covered on our entity resolution page.
Keep business-specific logic out of silver. If a rule only matters to the finance report, it belongs in gold. Silver should be true for everyone.
Gold: built for a purpose
Gold tables exist because someone needs an answer. Monthly revenue by region. Features for a churn model. The figures behind a regulatory return.
They're shaped for reading: aggregated, denormalised, named in business terms. There can be many of them, and that's fine, as long as each is built from silver and not from another team's gold or, worse, straight from bronze.
This is the layer your dashboards should read from. When two reports disagree, the cause is nearly always that one of them skipped silver and applied its own cleaning rules.
Why three layers and not one
Each layer answers a different question when something goes wrong. Is the number wrong because the source sent bad data? Check bronze. Because a cleaning rule is off? Check silver. Because the report defines the metric differently? Check gold.
Without the separation those three questions blur into one long afternoon. With it, a fix has an obvious home and a limited blast radius.
It also lets different people work at different levels safely. Analysts build in gold without being able to damage the cleaned data. Engineers change ingestion without breaking reports.
Mistakes that undo it
- Treating the layers as folders. If silver is a copy of bronze with new column names, you have three copies of the same mess. The layers are defined by quality, not by location.
- Cleaning in bronze. Once raw data has been edited, you've lost the ability to replay.
- Business logic scattered across silver. Rules that belong to one report end up applied to everyone.
- Gold built from gold. Dependencies between published tables turn every change into an investigation.
- No tests between layers. A layer nobody checks is only a naming scheme.
You also don't need exactly three. Some teams add a staging step, some split gold by department. Three is a starting point that's easy to explain, which is most of its value.
Does every team need it?
A small team with four sources and ten reports can do well with something simpler: raw tables and a set of clean models on top. Don't build ceremony you won't maintain.
The pattern starts paying when several teams read the same data, when sources are unreliable, or when you need to prove where a number came from. That describes most regulated businesses.
If you're setting up a lakehouse or tidying an existing one, this is part of what we do in data engineering and platform builds.
