One thing always bothered me about the Medallion Architecture. Every explanation looked the same:
Bronze
↓
Silver
↓
Gold
Bronze stores raw data. Silver cleans and standardises it. Gold prepares it for reporting.
My first thought: so we’re storing the same table three times? A customer’s name is misspelled in Bronze, we fix it in Silver, a business rule changes and we build yet another version in Gold. There had to be a better reason than progressive cleansing.
I couldn’t find one. For a long time I quietly assumed Medallion was a marketing diagram that escaped containment.
The Explanation That Never Satisfied Me
Picture it: CRM and ERP feed into Bronze, which flows to Silver, which flows to Gold. Bronze is raw, Silver is curated, Gold is business-ready. Technically correct. But it never explains why anyone should pay for three copies of everything.
Worse, it never says what each layer is actually responsible for. If Silver is just cleaner Bronze, why not clean Bronze in place? Why the separation? I’d nod along in architecture reviews, then go back to my desk and wonder if I was missing something obvious.
Looking Backwards Instead of Forwards
I was. But the answer wasn’t in modern data docs. It was in something much older.
Twenty years ago, enterprise warehouses looked nothing like Medallion. They had an Operational Data Store (ODS) between the operational systems and the data marts:
Operational Systems
│
▼
Operational Data Store (ODS)
│
├──▶ Data Mart (Claims)
├──▶ Data Mart (Sales)
└──▶ Data Mart (Finance)
The ODS was the integration layer. Microsoft Fabric docs describe it as a “subject-oriented, integrated, and near real-time store that consolidates data from multiple operational systems into a lightly curated, normalized model.” It absorbed changes, standardised keys across sources, reconciled duplicates, and became the trusted operational record before anyone touched analytics.
The data marts queried the ODS and transformed for specific business domains. Clear division of work: the ODS owned “what happened, with trust,” the marts owned “what it means for my domain.”
I’d worked with this pattern for years. Then it got rebranded as Bronze, Silver, Gold, and I forgot everything I already knew.
Silver Is the Modern ODS
Here’s what clicked. Silver is not cleaner Bronze. Silver is the ODS. Not because the data is cleaner, but because Silver is where the architecture makes its promises:
- History preservation: every change, not just the latest state
- Reconciliation: cross-system keys resolved here
- Change data capture: the append log lives here
- Deduplication: one trusted version of each entity
- Schema evolution: new fields arrive, old queries still work
- Audit trail: who changed what, and when
Those aren’t cleaning jobs. They’re governance jobs. Exactly what the ODS used to own.
Gold doesn’t own those things and shouldn’t. Gold’s job is simpler: answer the business question.
Gold Becomes Surprisingly Simple
Bronze (immutable landing zone)
│
▼
Silver (enterprise ODS — history, CDC, audit)
│
├──▶ Customer Gold
├──▶ Claims Gold
├──▶ Sales Gold
└──▶ Finance Gold
Gold becomes disposable. Lose a Gold table? Rebuild it from Silver. Business wants a new metric? Add another Gold view. Marketing wants a different customer segmentation? Build a new mart. Silver stays untouched.
That’s the shift: Silver is the investment, Gold is the product. Once Gold is disposable, you stop being afraid of changing it, and that changes how you design pipelines.
Why Lakehouses Made This Practical
None of this was new. Architects understood the split between operational integration and analytical models twenty years ago. The problem was cost. Relational platforms made history expensive.
Keeping full operational history meant SCD Type 2 logic, effective date ranges, and tables where every update closed one date range and inserted a new version. Millions of rows, every night. Many organisations gave up, kept the latest state, and deferred history until someone actually needed it.
Lakehouses changed the economics. With immutable storage and transaction logs, keeping previous states became a natural pattern instead of a burden. Delta Lake gave us Time Travel:
SELECT * FROM silver_customer VERSION AS OF 42
SELECT * FROM silver_customer TIMESTAMP AS OF '2026-01-15'
But Time Travel is not business history.
Time Travel lets you query a table as it existed at a previous point in storage. Useful for debugging, reprocessing, rollback. It doesn’t tell you what changed from a business perspective.
Say you ingest Bronze append-only. You see customer_001 with Sydney, then Melbourne, then Brisbane. Multiple versions exist. Did Melbourne replace Sydney? Was Sydney a correction, an old address, or a duplicate? The data won’t say. You’d need a CDC feed from the source, a structured change log with operation types and timestamps, to reconstruct what each transition meant.
A history-preserving Silver layer still needs modelling decisions: CDC ingestion, effective dating, version columns, merge logic. Delta Lake didn’t make CDC native. It made immutable storage and versioned data practical. CDC is still a data movement pattern you capture at the source.
The point: lakehouses made these patterns affordable. History stopped being an expensive feature you bolt on later. It became the default. The barriers that kept teams from building a proper history-preserving ODS were gone.
Silver could finally become the modern Operational Data Store. Not because Delta Lake did the modelling for you. Because it made the modelling worth doing.
My New Mental Model
I don’t think about Medallion this way anymore:
Bronze = Raw
Silver = Cleaned
Gold = Reporting
I think about it this way:
Bronze = Immutable landing zone
Silver = Enterprise Operational Data Store
Gold = Business data products (data marts)
The responsibilities are distinct. The value is clear. The architecture has a business justification that goes beyond “clean data flows downhill.” Databricks’ own guidance hints at it: the gold layer “can contain one or more data marts,” silver “should serve as the single source of truth for your data marts.” Most diagrams skip that connection. They show the layers without telling you this is a twenty-year-old conversation that Delta Lake just made cheaper.
The Real Lesson
This wasn’t a technical insight. It was an architectural one. Medallion isn’t valuable because data gets cleaner at each layer. It’s valuable because each layer has a fundamentally different job. Bronze captures what happened, no questions asked. Silver is the trusted historical record, the ODS modernised. Gold answers business questions, disposable by design.
Once I stopped seeing Silver as “cleaned Bronze” and started seeing it as the modern ODS, the whole thing made sense. The diagrams were technically right about data flow. They were wrong about the point. If you’ve ever looked at a Medallion diagram and thought “this is just three copies of the same table with extra steps,” you’re not wrong. You’re just looking at it wrong.
Stop thinking of Silver as cleaned Bronze. Think of it as the ODS, minus the cost. Do that, and Medallion finally makes business sense.