At a glance
- Bronze should preserve what the source sent, with history and minimal interpretation.
- Silver is where most integration complexity belongs.
- Small environments may only need a thin silver layer.
- Large enterprises may legitimately need multiple silver sub-layers.
- Gold should be shaped around the consumption requirement, not around a textbook model.
Bronze, silver, gold. It sounds like a new pattern that came bundled with the modern lakehouse.
It isn’t. Bronze is your old ODS. Gold is your old datamart. The names changed, the tooling improved, but the shape of the problem is decades old. What’s actually new is that we now have a name, and a place in the architecture, for the layer in between, the one that was always doing the hard work and rarely got the credit: silver.
Most medallion implementations get into trouble because they treat all three layers as equally variable, when only one of them actually is. Bronze gets over-engineered with premature business logic. Gold gets treated as a dumping ground because “we’ll model it properly later.” Silver gets either ignored as an afterthought or left to sprawl into an unmanageable pile of one-off transformations.
This is also why data platform modernisation needs to focus on the architecture around the platform, not just the technology itself.
The pattern that actually works is simpler than most implementations make it: bronze and gold should stay simple by design, and silver should be as complex as your environment genuinely requires, and no more.
Bronze: source data, with history
Bronze has one job. Capture what the source system sent, when it sent it, without deciding what any of it means yet.
That’s the ODS, plainly. No business rules, no deduplication logic, no “let’s just fix this one obviously wrong value while we’re here.” The moment you make judgment calls in bronze, you lose the one thing a raw layer exists to answer: what did the source actually look like at this point in time?
In practice
- Append-only capture, or CDC that preserves change history rather than collapsing it
- Source-native structure and types, not the shape you wish the data had
- Minimal, pipeline-controlled metadata (ingestion timestamp, source system, batch/run identifiers), so lineage is never in question
- No joins, no filtering out “bad” records, no silent corrections
If bronze is simple, it’s robust. It doesn’t break when downstream requirements change, because it was never coupled to them. A messy source doesn’t make bronze complicated, it just makes bronze messy, which is exactly what bronze is for.
Silver: still the hard part
This is where the real work has always lived, whether we called it staging, an integration layer, MDM, or nothing at all because it was just quietly scattered across a hundred ETL jobs.
In a medium to large enterprise, silver is where a vast array of transformative processes has to be brought into some kind of order: conforming entities across systems that were never designed to agree with each other, resolving master data, applying business rules that differ by domain, historising state, gating quality, staging conformance before anything reaches a dimensional model. That’s not new complexity created by the lakehouse. It’s the same integration problem data warehousing teams have wrestled with for thirty years, now given an explicit layer of its own instead of being buried across a maze of stored procedures.
Typical silver responsibilities
- Entity conformance across source systems
- Master data and entity resolution
- Domain-specific business rules
- Historised state tracking
- Data quality gating
- Conformance before data reaches a dimensional model
When silver should stay simple
At the small end, silver can genuinely be simple: a handful of cleansing rules, type conformance, deduplication, maybe a light conformance to a shared entity key. One layer, a few transforms, done. For a small platform with a handful of sources, anything more is pure overhead: operational cost and failure points for a capability nobody asked for.
When silver needs more structure
At the large end, silver is legitimately multi-layered: staged conformance, master data and entity resolution, domain-specific business rules, historised state tracking, data quality gating, domain modelling before it ever reaches gold. Organisations with many overlapping source systems and enterprise-wide governance requirements need this. Collapsing it into “one clean silver table” just pushes that complexity into gold, where it doesn’t belong, or into ad hoc BI-tool logic, where nobody can govern it.
The mistake runs both ways
The mistake runs both ways. Small teams building enterprise-grade multi-layer silver because “that’s what the reference architecture shows” waste effort maintaining infrastructure their scale doesn’t need. Large enterprises trying to keep silver to one thin layer end up smuggling entity resolution and business rules into gold or bronze instead, quietly breaking the simplicity of both.
The right question was never “how many sub-layers should silver have.” It’s “how much genuine integration complexity exists across our sources, and are we making that complexity visible and governable, or just hiding it somewhere else.” That question is exactly the one ODS-to-datamart architects were answering long before anyone called it medallion.
Gold: whatever satisfies the requirement, nothing more
Gold is the datamart, and it earns its simplicity the same way datamarts always did: by being scoped entirely to consumption, not to the platform underneath it.
Sometimes that’s a properly Kimball-modelled star schema, conformed dimensions, slowly changing dimensions, the works, because the reporting layer genuinely benefits from that structure.
Sometimes it’s a large, flat, denormalised table, because the reporting tool is a self-service BI tool that performs best against a single wide table, and the users don’t want to navigate a star schema. A flat file that answers the business question clearly is not a lesser design. It’s the right design when the consuming tool and audience call for it.
The test for gold is never “did we build a textbook model.” It’s “does this satisfy the requirement in a form the consumer can actually use.”
Don’t build more than the requirement asks for, and don’t let gold turn into a second silver by accumulating general-purpose logic that no specific requirement ever needed.
What each layer is responsible for
|
Bronze
Preserve the source and its history |
Silver
Resolve the genuine integration complexity |
Gold
Serve the specific consumption need |
Why this framing matters
Medallion architecture is often taught as a fixed three-tier pipeline, as if every implementation should look identical. It shouldn’t. What should stay constant is the contract at each end: bronze is a faithful, historised copy of the source, gold is a purpose-built answer to a specific consumption requirement. Everything else, all the genuine complexity of reconciling messy, overlapping, evolving source systems into something trustworthy, belongs in silver, sized to the environment it actually serves.
Platforms such as Databricks give teams the tooling to implement these patterns, but the architecture still needs to reflect the complexity of the environment it serves.
Get bronze and gold right by keeping them boring. Get silver right by being honest about how much integration work your environment actually requires, and building exactly that much.
That’s not a new lesson. It’s the oldest one in data warehousing, just wearing a new coat of paint.
