Medallion architecture is a way of organizing data into three layers, usually called bronze, silver and gold, so that each layer is cleaner and more useful than the one before it. It is a naming convention for a pattern many teams already follow, which is why it is easy to adopt and easy to over-engineer.
The three layers
The bronze layer holds raw data exactly as it arrived from the source, with little or no change. The silver layer holds cleaned and conformed data: duplicates removed, types fixed, and records joined or standardized so they can be trusted. The gold layer holds data shaped for a specific business use, such as aggregated tables, metrics and models that dashboards and reports read directly.
Why keep a raw layer
Keeping bronze untouched means you can rebuild silver and gold whenever your logic changes, without going back to the source system. It also gives you an audit trail of what was received and when. This is the same reasoning behind loading first and transforming later, covered in ETL vs ELT.
What belongs in silver
Silver is where data quality work happens: removing duplicates, enforcing types, handling nulls, and applying consistent keys. If you track how records change over time, this is also where patterns such as slowly changing dimensions are applied. A good test for silver is that an analyst could query it without having to understand quirks of the source system.
What belongs in gold
Gold is organized around questions the business asks, not around source systems. Typical contents are star-schema fact and dimension tables, daily or monthly aggregates, and metric tables. Keep business logic here, in one place, so two dashboards do not calculate the same number in two different ways.
Where it fits with warehouses and lakes
Medallion architecture is most associated with lakehouse platforms, but the idea does not depend on any one tool. You can apply the same three tiers inside a warehouse using schemas, or across a lake and a warehouse. If you are still choosing a platform, start with data warehouse vs data lake vs lakehouse.
Running the layers
Each hop between layers is a pipeline step with its own schedule, which is where orchestration comes in. Decide for each hop whether it reloads everything or only changes, using the trade-offs in incremental load vs full refresh. Add checks between layers, in the spirit of data observability, and track how a gold number traces back to bronze with data lineage.
When three layers are too many
A small project may not need all three. Extra layers add pipelines to maintain, and each one is another place for something to break. If your data is small and comes from one clean source, a raw area and a modeled area can be enough. Add layers when you have a reason, such as messy sources, multiple consumers, or a need to reprocess history.
A quick checklist
- Is raw data stored unchanged so you can rebuild downstream layers?
- Does silver apply cleaning and consistent keys, without business logic?
- Is business logic defined once, in gold?
- Are there checks between layers that alert you to bad data?
- Do you actually need three layers, or would two do?
If you are designing a warehouse or lakehouse and want a second opinion, see my cloud data warehousing service.
FAQ
What is medallion architecture?
It is a data design pattern with three layers: bronze for raw data, silver for cleaned and conformed data, and gold for business-ready tables.
Is medallion architecture only for Databricks?
No. The term is popular on lakehouse platforms, but the layered pattern works in any warehouse or lake.
Do I need all three layers?
Not always. Small, clean datasets can work with two layers. Add a layer when it solves a real problem, such as messy sources or several consumers of the same data.
