The Missing Business Case for Medallion Architecture

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 immediate reaction: 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 create yet another version in Gold. Surely there had to be a better reason than progressive cleansing.

I couldn’t find one, so for a long time I quietly assumed the Medallion Architecture was just a marketing diagram that had escaped containment.

The Explanation That Never Satisfied Me

Draw the picture: 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 storing three copies of everything.

Worse, it never explains 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 quietly question whether I was missing something obvious.

Looking Backwards Instead of Forwards

Turns out, I was. But the answer wasn’t in modern data docs. It was in something much older.

Twenty years ago, enterprise data warehouses looked nothing like Medallion. They had an Operational Data Store (ODS) sitting between operational systems and downstream 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 from operational systems, standardised keys across sources, reconciled duplicates, and became the trusted operational record before anyone touched analytics.

The data marts were downstream, querying from the ODS and transforming for specific business domains. The division of responsibility was clear: the ODS owned “what happened, with trust,” and the data marts owned “what it means for my domain.”

I’d worked with this pattern for years. But somehow, when it was rebranded as Bronze, Silver, Gold, I forgot everything I already knew.

The Breakthrough: 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 architectural 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 responsibilities. They’re enterprise data governance responsibilities, and they’re exactly what the ODS used to own.

Gold doesn’t own those things and shouldn’t. Gold’s job is much 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 needs a different customer segmentation? Build a new mart. Silver stays untouched.

That’s the power: the ODS (Silver) is the investment, the data marts (Gold) are the products. Because Gold is disposable, you stop being afraid of changing it, and that alone changes how you design pipelines.

Why Lakehouses Made This Practical

None of this was new thinking — architects understood the separation between operational integration layers and analytical models twenty years ago. The challenge was cost. Traditional relational platforms made history expensive.

Keeping a complete operational history meant implementing SCD Type 2 logic, managing effective date ranges, and maintaining ever-growing tables where every update required an UPDATE to close an effective-date range and an INSERT for the new version. Millions of rows, every night. Many organisations compromised, kept the latest state, and deferred history until someone eventually needed it.

Lakehouses changed the economics. With immutable storage and transaction logs, retaining previous states became a natural design pattern rather than an operational burden. Delta Lake introduced Time Travel:

SELECT * FROM silver_customer VERSION AS OF 42
SELECT * FROM silver_customer TIMESTAMP AS OF '2026-01-15'

But here’s the important distinction: Time Travel is not the same as business history.

Delta Time Travel lets you query a table as it existed at a previous point in storage — useful for debugging, reprocessing, and rollback. It doesn’t automatically tell you what changed from a business perspective.

Consider a Bronze append-only ingestion: you see customer_001 with Sydney, customer_001 with Melbourne, customer_001 with Brisbane. Multiple versions exist, but did Melbourne replace Sydney? Was Sydney a correction, a historical address, or a duplicate? The data doesn’t tell you. You’d need a CDC feed from the source — a structured change log with operation types and timestamps — to reconstruct the business meaning of each transition.

A history-preserving Silver layer still requires modelling decisions, whether through CDC ingestion, effective dating, version columns, or merge logic, to represent business changes. Delta Lake didn’t make CDC native. It made immutable storage and versioned data management practical. CDC is still a data movement pattern that requires capturing row-level changes at the source.

The breakthrough was that lakehouses made these patterns affordable. Instead of treating history as an expensive feature added later, organisations could make historical preservation the default. The storage and operational barriers that caused teams to avoid building a proper history-preserving ODS were suddenly gone.

The Silver layer could finally evolve into the modern Operational Data Store — not because Delta Lake did the modelling for you, but 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, and the architecture has a business justification that goes beyond “clean data flows downhill.” Databricks’ own guidance hints at this — the gold layer “can contain one or more data marts” and silver “should serve as the single source of truth for your data marts.” Most diagrams skip the connection, showing 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. The Medallion Architecture 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 and no transformations applied. Silver becomes the trusted historical record of the enterprise, the ODS modernised. Gold answers business questions, disposable by design.

Once I stopped thinking of Silver as “cleaned Bronze” and started seeing it as the modern ODS, the entire architecture snapped into focus. Every diagram I’d seen was technically right about the data flow, but they were missing the point about the responsibilities. 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.

💡 The key takeaway: Silver isn’t Bronze but cleaner. Silver is the ODS but cheaper. When you stop thinking about transformations and start thinking about responsibilities, the Medallion Architecture finally makes business sense.