How the bronze, silver and gold layers give you reliable reporting in a lakehouse, with examples from real data flows.
In short
Medallion architecture is a way of organising data in a lakehouse into three layers. Bronze keeps source data as it was received, silver cleans, validates and joins it, and gold publishes views built for specific business questions. The value is a traceable path from a source record to the number on a dashboard, with clear rules at every handover.
This guide comes from Devies, a Gothenburg-based product and engineering consultancy that builds and runs data platforms for Nordic companies. It explains what each layer is responsible for, how the pattern relates to the data lake and the data warehouse, and what it takes to operate it. Both Databricks and Microsoft Fabric document the pattern, and implementations differ, so treat it as a way to organise work rather than a fixed blueprint.
Why split data into layers at all?
Layers make it possible to answer "where did this number come from?" because each stage has one job and keeps its own copy of the data.
Most reporting problems are not caused by the dashboard. They come from a calculation that silently dropped records, a source that changed format, or two teams applying different rules to the same data. When everything happens in one step, between the source system and the report, there is nothing to compare against when a figure looks wrong.
A layered design gives you checkpoints. If a revenue figure is off, you can check whether the source delivered the right records (bronze), whether cleaning and matching went wrong (silver), or whether the business rule itself is wrong (gold). Databricks describes the layers as denoting the quality of data stored in the lakehouse, which is a useful way to think about it: quality goes up as data moves through.
The layer names alone do not make a number correct. Without agreed rules for each handover, a platform can have three neatly named folders and the same reporting problems as before.
What belongs in each medallion architecture layer?
Bronze holds raw source data, silver holds validated and joined data at record level, and gold holds business-ready views that answer defined questions.
Bronze: keep the starting point
Bronze is the landing layer for source data, stored as received with context such as source system, extraction time and load identifier. Minimal transformation happens here. The purpose is evidence: if a report is questioned, the team can show what the source actually delivered for that period. Retention and access rules still apply, so "raw" does not mean keeping every personal data field forever.
Silver: make data usable across systems
Silver is where cleaning and validation become explicit. Typical work includes consistent data types, duplicate handling, mapping identifiers between systems and checking records against agreed rules. Silver should keep data at record level rather than aggregate it. Records that fail a check should be visible in an exception list, not quietly disappear.
Gold: answer a business question
Gold is a set of curated tables or views organised around an agreed question, such as invoiced revenue by customer and month. It is the layer that dashboards, finance reports and AI services read from. Each gold table needs a documented grain, for example one row per invoice line, and named owners for its definitions.
Layer
Responsibility
Example acceptance check
Bronze
Responsibility
Receive the source extract unchanged, with load metadata
Example acceptance check
Load completed with a recorded source cut-off time
Silver
Responsibility
Clean, deduplicate and match records across systems
Example acceptance check
Duplicates and unmatched records are counted and reported
Gold
Responsibility
Publish an agreed business view
Example acceptance check
Totals reconcile with the source for a defined period
Data lake vs data warehouse: where does a lakehouse fit?
A lakehouse combines the cheap, flexible storage of a data lake with the structure and reliability of a data warehouse, and medallion architecture is the most common way to organise the data inside it.
The terms are often used loosely, so precise definitions help:
- A data lake is low-cost storage for large volumes of data in its original format, structured or not. It is flexible but, without discipline, hard to trust for reporting.
- A data warehouse is a structured database designed for analysis, with defined tables, schemas and business rules. It is reliable for reporting but less flexible for new or unstructured sources.
- A lakehouse is a platform that stores data in open formats on lake storage while adding warehouse features such as tables, transactions and access control.
Data lake
Data warehouse
Lakehouse
Data format
Data lake
Any, as received
Data warehouse
Structured tables
Lakehouse
Open table formats on lake storage
Typical use
Data lake
Storage, data science, archive
Data warehouse
BI and financial reporting
Lakehouse
Both, on one platform
Strength
Data lake
Flexibility and cost
Data warehouse
Consistency and performance
Lakehouse
Combines both if well governed
Main risk
Data lake
Becomes a "data swamp"
Data warehouse
Slow to add new sources
Lakehouse
Complexity without clear layer rules
In the data lake vs data warehouse debate, the layers bridge the gap. Bronze behaves like a classic data lake, while gold behaves much like a data warehouse. You do not always need three separate technologies; the pattern describes responsibilities, and physical separation depends on your platform and access needs.
Governance: who owns each layer?
Each handover between layers needs a named owner, agreed quality rules and a freshness expectation, otherwise the layers exist only on paper.
Technical ownership usually sits with data engineers for bronze and silver. Gold definitions, such as what counts as "revenue" or an "active customer", need a business owner who can say what is correct. When two departments see different figures for the same metric, the cause is usually two definitions in two places. Our planned article on why Power BI shows different numbers to finance and sales covers that problem in detail.
Practical governance questions to settle early:
- Who can rerun a load, and how are partial loads detected?
- What happens when a silver check fails: quarantine the record, or block the report refresh?
- How fresh must gold data be, and how do users see that it is stale?
- Where do reusable business rules live: in gold tables or in the Power BI semantic model? Microsoft's Power BI star schema guidance explains why the model still needs proper relationships and measures.
- Who approves changes to a gold definition, and how are report users told?
An example: from ERP invoice to revenue report
A simple, hypothetical revenue flow shows how the layers divide the work between ERP data, CRM data and a monthly report.
Bronze receives invoice lines from the ERP and account records from the CRM every night, each stamped with load time. Silver standardises currencies and dates, removes duplicate invoice lines, and maps ERP customer IDs to CRM account IDs. Accounts that cannot be matched go to an exception list that sales operations reviews weekly. Gold publishes invoiced revenue by customer, segment and month, with credit notes and currency rules documented. Power BI reads from gold, and finance and sales use the same table.
If a sales manager questions a figure, the team can trace it back: gold total, silver records behind it, bronze extract for the period.
The same principles work in larger, established platforms. In the Stena Line client case, Devies describes moving an existing data platform towards medallion-style layered flows on Azure, with controlled, traceable transformations, while existing reporting kept running. The case reports roughly a 25% reduction in pipeline runtime, but that figure belongs to that platform and is not a result every organisation should expect.
A small report from one dependable source may not need three layers. Multiple sources, recurring quality issues and several consumers of the same data are stronger reasons to adopt the pattern.
Keep reading
From our work
Client Case: Stena LineStena Line modernised its Azure data platform - improving Power BI reliability, reducing pipeline runtimes and scaling with medallion architecture.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What is medallion architecture in simple terms?
Medallion architecture is a way to organise data in three layers. Bronze stores data exactly as it arrived from source systems, silver cleans, validates and joins it, and gold publishes tables built for specific business questions. Each layer has one job, so when a report looks wrong, the team can trace the figure back step by step and find where the error was introduced.
Is the gold layer the same as a Power BI dashboard?
No. Gold is a prepared data layer, while a dashboard is a presentation built on top of data and a semantic model. Several reports, tools and AI services can read from the same gold tables. Keeping them separate means a business definition is implemented once in gold or in a shared model, rather than repeated differently in every individual report.
Do we need a lakehouse to use medallion architecture?
Not strictly. The pattern is most often described for lakehouse platforms such as Databricks and Microsoft Fabric, but the idea of separating raw, validated and business-ready data also works in a traditional data warehouse. What matters is that each stage has clear responsibilities, quality checks and owners, not which storage technology sits underneath.
Will medallion architecture fix inaccurate reports?
Not by itself. Layers make errors easier to find and correct, but wrong business definitions, faulty transformations or missing source data still need to be fixed. The improvement comes from the rules around the layers: validation in silver, documented definitions and owners in gold, and reconciliation of report totals against agreed source data for a defined period.
