The Medallion Architecture Civil War: Silver vs. Gold for Fact and Dimension Tables

The medallion architecture, Bronze for raw ingestion, Silver for cleansed/conformed data, Gold for business-ready consumption, is supposed to be the great unifier of modern data platforms. Instead, it’s become a battleground for one of the most fundamental questions in dimensional modeling: where do fact and dimension tables actually live?

The Core Conflict: Two Philosophies, One Architecture

The Reddit thread that kicked this off was deceptively simple. User Difficult_Neck_2709 asked: “I’ve been seeing multiple examples where people don’t seem to agree whether fact and dim tables go in Silver or Gold layer. What’s your opinion?”

The top comment, with 32 upvotes, cut straight to the heart of the matter: “They don’t seem to agree because neither is entirely wrong. They come from two philosophies.”

This isn’t a case of someone being wrong on the internet. It’s a genuine architectural tension that maps directly onto the decades-old Inmon vs. Kimball debate. If you think medallion architecture settled this, you haven’t been paying attention.

The Two Camps: A Tale of Two Philosophies

The disagreement isn’t random confusion, it’s a collision of two fundamentally different approaches to data architecture.

The BigBasket Case Study: A Real-World Answer

This isn’t just theoretical hand-wringing. A recent AWS blog post detailing how BigBasket, India’s largest online grocery platform, implemented their lakehouse architecture provides a concrete, real-world answer.

BigBasket’s architecture, which powers lightning-fast grocery delivery across 60+ Indian cities, places fact and dimension tables squarely in the Silver layer.

According to the AWS blog post detailing their implementation: “Silver layer: Represents the conformed data model, where data is cleansed, standardized, and validated with enforced quality checks. This layer contains core dimension and fact tables, modeled for analytical consistency and reuse across domains.”

The Gold layer, by contrast, is described as providing “business-ready data marts and wide tables optimized for reporting, dashboarding, and domain-specific use cases.”

This is a clear, authoritative answer from a production system handling millions of transactions. But it’s not the only answer.

Why This Debate Matters (And Why It’s So Confusing)

The confusion stems from a fundamental ambiguity in the medallion architecture itself. The framework was popularized by Databricks as a simple, intuitive pattern: Bronze for raw, Silver for cleansed, Gold for business-ready. But “business-ready” is a squishy term. For some teams, a conformed dimensional model is business-ready. For others, business-ready means pre-aggregated dashboards with specific KPIs.

This ambiguity is why the debate keeps resurfacing. As one commenter noted, the disagreement ultimately traces back to the Inmon vs. Kimball divide, a war that’s been raging since the 1990s and shows no signs of ceasefire.

The Inmon vs. Kimball Ghost

If you want to understand why fact and dimension tables are a battlefield, you need to understand the two fathers of data warehousing.

As one Reddit commenter distilled it: “It always boils down to Inmon vs. Kimball. Whether or not you have an integrated EDW in between.”

This isn’t a new debate. It’s the same fight, just with shinier branding.

The Practical Middle Ground: What BigBasket Actually Did

The BigBasket case study is instructive because it represents a real-world decision made by a team under pressure. They weren’t debating philosophy, they were building a platform to handle 35,000+ reports and dashboards with sub-5-minute data freshness.

Their answer: Silver gets the dimensional model. Gold gets the business marts.

The Silver layer in their architecture contains “core dimension and fact tables, modeled for analytical consistency and reuse across domains.” The Gold layer provides “business-ready data marts and wide tables optimized for reporting, dashboarding, and domain-specific use cases.”

This is a pragmatic middle ground. The dimensional model lives in Silver as the canonical, reusable analytical foundation. Gold adds the final layer of business-specific aggregation and presentation.

The “It Depends” Framework: Making the Decision for Your Team

The most useful comment on the thread came from a user who laid out a decision framework rather than a dogmatic answer:

“If analytics is the entire goal of your platform, go with the dimensional model in Silver as it serves the majority of use-cases. If analytics is just a part of a broader data landscape, then it’s better to have the Silver as a SOR in 3NF and build a dimensional model in Gold.”

This is the kind of practical guidance that actually helps teams make decisions. Let’s break it down.

The Hybrid Pattern That Actually Works

The most pragmatic teams don’t pick a side, they build a bridge. One commenter described a pattern that’s increasingly common in production:

“I’ve seen patterns where data is split and loaded into Facts and Dims in the Silver layer itself and are transferred across to Gold with a 1:1 mapping. Basically, the transformation logic for the facts and dims are applied at the Silver layer itself and Gold is just a 1:1 transfer of the already transformed data. But downstream applications such as Power BI are always expected to query the facts and dims from the Gold layer only.”

This is the architectural equivalent of having your cake and eating it too. The dimensional modeling logic lives in Silver, where it benefits from the layer’s data quality and standardization guarantees. But the Gold layer is the exclusive consumption interface. Downstream tools never touch Silver directly.

The result: a clean separation of concerns with a single source of truth for the dimensional model.

What BigBasket’s Architecture Actually Tells Us

The BigBasket case study is particularly valuable because it’s not a theoretical exercise. It’s a production system handling millions of transactions across 60+ cities, with near real-time data availability (3-5 minutes) and over 35,000 reports and dashboards.

Their architecture places fact and dimension tables in Silver, but with a critical nuance: the Gold layer is where business-specific data marts live. The dimensional model in Silver is the canonical, reusable foundation. The Gold layer adds the final mile of business context.

This is a pragmatic compromise that avoids the extremes of both camps. The dimensional model isn’t deferred to Gold (avoiding the Inmon-style normalization overhead), but it’s also not the final consumption layer (avoiding the rigidity of a single dimensional model serving all use cases).

The Real Problem: Medallion Architecture Is Underspecified

The deeper issue here is that medallion architecture, for all its popularity, is fundamentally underspecified. The Bronze-Silver-Gold metaphor is intuitive, but it leaves enormous room for interpretation. What exactly does “cleansed and conformed” mean? How much transformation happens in Silver vs. Gold? Where do you draw the line between “analytical consistency” and “business-ready”?

This ambiguity is why the broader debate on Silver vs. Gold layer definitions continues to rage. The medallion architecture promised standardization but delivered a framework that’s more of a suggestion than a specification.

The BigBasket Blueprint: A Production-Proven Answer

BigBasket’s implementation provides a concrete reference point. Their architecture, which processes data for India’s largest online grocery platform, places fact and dimension tables in Silver. But the nuance is critical.

The Silver layer in their architecture is not just cleansed data, it’s a conformed dimensional model. Fact and dimension tables are modeled for analytical consistency and reuse across domains. This means a single order_facts table in Silver serves marketing, operations, finance, and supply chain teams alike.

The Gold layer then adds domain-specific data marts and wide tables. Marketing gets a pre-joined customer lifetime value mart. Operations gets a fulfillment efficiency dashboard. Finance gets a revenue recognition view. Each Gold dataset is optimized for a specific consumption pattern, but they all trace back to the same Silver dimensional foundation.

This hybrid approach avoids the worst pitfalls of both extremes. You don’t have to rebuild dimensional models for every Gold consumer (the risk of putting everything in Gold). And you don’t have to force every business unit to query a single, rigid dimensional model (the risk of putting everything in Silver).

The Silver Layer Bottleneck

There’s a growing concern that the Silver layer is becoming a bottleneck in medallion architecture. When fact and dimension tables live in Silver, that layer becomes the single point of truth for all analytical modeling. Any change to the dimensional model ripples through every downstream consumer.

This is fine if your business is stable and your dimensional model is mature. But in fast-moving organizations where business definitions change weekly, a rigid Silver dimensional model can become a source of friction. Teams start building their own fact tables in Gold to escape the bottleneck, and suddenly you have dimensional model drift.

The BigBasket architecture handles this by keeping the Silver dimensional model relatively stable and using Gold for business-specific variations. The Silver fact tables capture core business events at a consistent grain. Gold adds the business context, the specific KPIs, the pre-joined dimensions, the filtered views that different teams need.

The Kimball Trap: Why “It Depends” Is Actually Useful

One commenter on the thread made a sharp observation about Kimball’s original work: “Probably in the first chapter or even before, he says that building DW requires effort of the whole organization. That I believe the most misunderstood part of the book. It is impossible to build it if you don’t have everyone onboard with it.”

This is the hidden cost of the dimensional model in Silver. A conformed dimensional model requires organizational alignment. Every business unit has to agree on what “customer” means, what “revenue” means, what “order” means. If your organization can’t achieve that alignment, your Silver dimensional model will be a source of constant conflict.

This is why some teams prefer the normalized Silver approach. A 3NF Silver layer doesn’t require the same level of organizational consensus. It’s a technical integration point, not a business agreement. The dimensional model in Gold can then be tailored to each business unit’s definitions without polluting the canonical view.

What the BigBasket Architecture Actually Proves

The BigBasket case study is often cited as proof that fact and dimension tables belong in Silver. But a closer reading reveals more nuance.

BigBasket’s Silver layer contains “core dimension and fact tables, modeled for analytical consistency and reuse across domains.” This is a dimensional model, but it’s not the dimensional model. It’s a set of core, reusable tables that serve as the foundation for multiple Gold-level data marts.

The Gold layer, meanwhile, contains “business-ready data marts and wide tables optimized for reporting, dashboarding, and domain-specific use cases.” These are not just copies of the Silver dimensional model. They’re purpose-built views that add business context, pre-join dimensions, and compute KPIs.

This is the hybrid pattern in action. The Silver dimensional model provides consistency and reuse. The Gold data marts provide flexibility and business specificity. Neither layer is “wrong”, they serve different purposes.

Making the Decision for Your Team

So how do you decide? Here’s a practical framework based on the patterns emerging from production systems:

The SQL vs. PySpark Angle

There’s a related debate about how the Gold layer should be built that intersects with this question. The SQL vs. PySpark in the Gold layer discussion reveals that teams are increasingly reaching for plain SQL when they hit the final stage of their pipelines, even after using PySpark for earlier transformations.

This matters for the fact/dimension debate because the tooling you use for each layer influences where you put your dimensional model. If your Silver layer is built with PySpark on Spark clusters, and your Gold layer is built with SQL on a query engine like Trino or Redshift, the dimensional model’s location determines which tooling and skill sets are required to maintain it.

BigBasket’s architecture uses dbt with the Trino adapter for transformations, running on top of Apache Iceberg tables. This SQL-first approach to the Silver layer makes dimensional modeling more accessible to analysts and data modelers who may not be comfortable with PySpark. It’s a practical consideration that often gets overlooked in architectural debates.

The Iceberg Advantage: Why Table Format Matters

One factor that’s changing the calculus is the rise of open table formats like Apache Iceberg. BigBasket’s architecture stores all Silver and Gold data as Iceberg tables on Amazon S3, which provides ACID transactions, time travel, and schema evolution.

This changes the fact/dimension placement debate in subtle but important ways. With Iceberg, the distinction between Silver and Gold becomes more about logical organization than physical separation. Both layers can share the same storage, the same table format, and the same query engines. The difference is in how the data is modeled and who consumes it.

This is why the critique of medallion architecture as repackaged patterns has some merit. The Bronze-Silver-Gold framework is essentially a rebranding of concepts that data warehouses have used for decades. What’s new is the technology stack, open table formats, cloud object storage, and decoupled compute, that makes the layers more flexible and less rigid.

The Practical Answer: Stop Debating, Start Deciding

After digging through the Reddit thread, the BigBasket case study, and the broader industry patterns, here’s the uncomfortable truth: there is no single right answer. The medallion architecture is a framework, not a specification. The right placement depends on your organization’s maturity, consumption patterns, and tolerance for ambiguity.

But that doesn’t mean the question is unanswerable. Here’s a decision tree that actually works:

1. Do your business units agree on core definitions? If yes, put the dimensional model in Silver. If no, keep Silver normalized and build dimensional models in Gold.
2. Is analytics your primary use case? If yes, Silver dimensional model. If you’re also serving ML, operational systems, and data science, consider a normalized Silver.
3. Do you have a single, dominant consumption pattern? If most users query the same star schemas, Silver dimensional model. If different teams need different grains and dimensions, Gold.
4. How mature is your dimensional model? If it’s stable and well-understood, Silver. If it’s still evolving and subject to frequent changes, Gold gives you more flexibility to iterate.

The historical context of data warehousing patterns reminds us that this debate is as old as the field itself. Inmon and Kimball were arguing about this in the 1990s. The medallion architecture didn’t resolve it, it just gave it new labels.

The Bottom Line

The fact and dimension table placement debate isn’t a bug in the medallion architecture. It’s a feature. The framework is flexible enough to accommodate different architectural philosophies, which is why it’s been so widely adopted.

The teams that succeed aren’t the ones that pick the “right” answer. They’re the ones that make a deliberate choice, document their reasoning, and build their pipelines consistently. The worst outcome isn’t putting fact tables in Silver when they “should” be in Gold. It’s having some fact tables in Silver, some in Gold, and no one knows why.

So pick a lane. Document it. And move on to the problems that actually matter, like whether your data is clean, your pipelines are reliable, and your business users can get the answers they need.

The medallion architecture is a tool, not a religion. Use it accordingly.