Medallion architecture: what it is, when to use it, when it is overkill

Cover image

Three stacked layers inside a dark screen, each narrower than the one below. The content moves from one to the next and grows more organised: loose records at the bottom, a regular grid in the middle, and three summed bars on top.

Sales changed the commission rule mid-quarter, and somebody has to reflect that on the dashboard by Friday.

The rule lives inside the query that feeds the dashboard. The same query that cleans up the state field, converts the amount that arrived as text and joins four tables.

The problem is that touching the rule means touching all of that at once. And nobody can say, before running it, whether revenue will still add up afterwards.

In this article we explain what belongs in each layer of the medallion architecture, why the separation avoids that rework, and when three layers are more than the problem calls for.

What the medallion architecture is

It is an organising pattern, not a technology. The name comes from medals — bronze, silver and gold, in rising quality — and with each hop the data gets more structured and more trustworthy.

Databricks popularised the term while describing how to organise a lakehouse — the storage that holds raw files and analytical tables in the same place. But the pattern depends on no vendor, and works the same on a relational database, a warehouse or file storage.

Following the medallion architecture is a recommended best practice, not a requirement.

The sentence comes from Databricks’ own documentation, and it is worth holding on to for the last section of this article.

Figure 1 — the same record across the three layers

Three stacked bands with the same order crossing all of them. In bronze it appears as it came from the source, with the amount as text and the state spelled two ways. In silver, converted and standardised. In gold, summed by month and by state. To the right of each band, who consumes that layer.

Bronze: the data as it arrived

The bronze layer keeps the data exactly as it came from the source: no cleaning, no fixing and no standardising, errors included.

Keeping wrong data on purpose sounds counterintuitive, and the reason is practical: bronze is the safety net. When a rule in the next layer turns out to be wrong — and it does — you reprocess from bronze instead of pulling everything from the source again.

The source may no longer hold that history, it may have changed shape, and it may be down on the very day you need it.

• Record when and where the data came from. Load date and source identifier, in columns of their own. Without them, reprocessing becomes guesswork.
• Append only, never overwrite. If bronze is replaced on every load, it stopped being a safety net and became just a copy of the current state.

What does not belong here: business rules, joins between tables, type conversion and deduplication. All of that is the next layer.

Silver: where the work happens

The silver layer is where data is cleaned, standardised and integrated. It is the one that takes the most work and shows up the least in a presentation.

• Type conversion. Text becoming a number, text becoming a date. The R$ 1.234,56 that arrived as text and the 19/08/2026 in the local format.
• Standardisation. S and N from one system, 1 and 0 from another, true and false from a third, all becoming the same thing.
• Deduplication. The same customer registered in three sources.
• Validation. A required field that arrived empty, a key that should be unique, a value outside the accepted list.
• Joins between related tables. Order with customer, customer with region.

The result is trustworthy, detailed data, still without aggregation. It is the layer the analyst uses to investigate, and the one the data scientist prefers, because it keeps the detail.

What does not belong in silver is the rule that depends on a company decision: targets, commission, customer tiering. That is gold.

Gold: what the dashboard consumes

The gold layer is data ready for the business. Aggregated, modelled and organised the way the question is asked.

Revenue by month and by region. Commission calculated under the current rule. Customers tiered by spend. Fact and dimension tables, if the model is dimensional.

It is the layer closest to the dashboard and the most volatile, because business rules change often. It is fine that they change, as long as they change only there.

And that is the reason for the whole pattern. When sales asks to alter the commission rule, the work stays confined to gold: the cleaning still holds, the raw data is still stored, and no other report is affected.

A business rule should fit in one place.

When a third layer costs more than it helps

This is the part most texts on the subject leave out.

Three layers for a five-table pipeline is too much structure for too little problem. Each layer is more code to maintain, more storage to pay for and one more step to debug when the number does not add up.

Two layers are enough when the sources are few and stable, there are no complex joins between them, and the business rule is simple enough to live next to the cleaning without becoming a knot.

Three layers pay off when any of these is true:

• Several sources have to be reconciled with each other. The same customer, the same product, the same order, spelled different ways.
• More than one person touches the model. The separation becomes a contract between whoever maintains the cleaning and whoever maintains the rule.
• The business rule changes often. Each change should touch one layer, not five queries.
• You have needed to reprocess and had nowhere to reprocess from. Once is enough for bronze to pay for itself.

The most reliable signal is not data volume. It is another one: how many times have you had to change five places to change one rule? If the answer is never, the extra layer probably does not pay for itself yet.

Where Januss comes in

The medallion is a pattern, not a feature. No tool "has" medallion architecture — what changes is how much work it takes to implement.

In Januss, the three layers are steps of the same pipeline.

Bronze is the load. The data arrives from the source into the destination, with the sync mode chosen per table: full refresh, incremental, mirroring or versioned history. For databases, the reading comes from the transaction log, which also preserves deletions — information bronze needs to keep and a scheduled query cannot capture.

Silver is the conversion plus the SQL steps. Thirteen conversion rules you chain per column, with eight regional formats, and a per-column decision on the value that does not convert: stop the run or write null. Then SQL steps running inside the destination database, with dependencies between them and declared tests that can stop the load instead of merely warning.

Gold is the last step. Aggregation SQL, materialised as a table or as a view, depending on what the dashboard needs.

And there is a cost detail worth knowing before you model. Januss bills per row written, counting each step that writes. In a three-layer architecture, the same row can be counted three times. The way out is simple: a transformation materialised as a view copies no data and consumes no allowance. If silver does not need to be written, it is free, and only gold counts.

Two things show up in nearly every text about the medallion, and Januss does neither. It does not draw a lineage map between the layers, and it is not a data catalogue.

What it does know is which step depends on which, and it uses that to run them in the right order. That settles execution, not documentation: there is no screen showing where each column in the gold layer came from.

Want to build the three layers with a source of your own? The 14-day trial does not ask for a card: create your workspace.

Sources

The definition of the pattern and the sentence quoted above come from the Databricks documentation, opened on 27 August 2026:

• Databricks — What is the medallion lakehouse architecture?