Medallion vs dimensional modeling: two answers to two different questions

Medallion answers a lifecycle question. Bronze holds source data as it arrived, with the ingestion metadata attached and no business logic applied. Silver holds integrated, deduplicated, typed entities where the source-specific weirdness has been resolved. Gold holds what consumers are allowed to build on. The layers are about trust and reprocessing, which is why the rule of thumb is that you should be able to rebuild silver from bronze and gold from silver.

Dimensional modeling answers a consumption question. What does one row mean, which attributes can slice it, which measures are additive, and what happens when an attribute changes. Those questions do not go away because a table lives in a Delta or Iceberg format under a gold schema.

Once you see them as separate axes, most of the confusion resolves. Medallion tells you where a table sits in the refinement pipeline. Dimensional modeling tells you what its rows mean. A fact table in gold satisfies both statements at once.

The common and defensible pattern: gold contains a dimensional core, with conformed dimensions shared across processes and atomic fact tables at a stated grain, plus a small number of published projections built from that core for specific consumers. Wide marts, metric tables, and ML feature tables are projections, not the core.

Silver is where the modeling style varies most between teams. Some keep it as cleaned one-to-one entities per source, integrated only on keys. Others historize it into a normalized or vault-style model so that gold can be rebuilt at any point in time. The second option costs more up front and pays back on the day someone asks for a restated history. The choice depends on how often that question actually gets asked.

Bronze should hold no business logic at all. The moment a transformation lives in bronze, reprocessing from source stops being possible, and the layer has lost the only property it was created for.

Gold as a dumping ground. Every team gets a gold schema, writes whatever their dashboard needs, and within a year gold has four definitions of revenue and no conformed dimensions. The fix is not a new layer, it is an owner for the dimensional core and a rule that projections may not source from each other.

Silver as a second copy. If silver is just bronze with column names cleaned, it costs storage and compute for nothing. Silver earns its place when it integrates several sources onto shared keys and resolves conflicts.

Layer inflation. Bronze, silver, gold, then platinum, then a curated layer, then a semantic layer. Every added layer doubles the reprocessing surface and the number of places a definition can hide. If a layer cannot be described in one sentence stating what it is allowed to do, it does not need to exist.

Confusing the layer with the container. Whether the layers are three catalogs, three schemas, or three prefixes is a packaging decision that depends on the platform, and it is covered separately for Unity Catalog and for Snowflake.

A diagram that shows only the three layers communicates nothing a slide title could not. A diagram that shows only the star loses the pipeline. Datadef draws both at once: zones for bronze, silver, and gold, the real tables inside each zone with their storage and engine icons, and labelled edges stating what each hop does, such as deduplicate on natural key or conform to dim_customer.

The layer is a first-class property of a node rather than a group label, which matters more than it sounds. Its vocabulary is fixed at source, ingest, bronze, silver, gold, consume, and dbt, table nodes infer their layer from their names, and the value drives the node accent. A table sitting inside the gold zone while carrying a silver accent is a naming problem showing itself before anyone reads the label, which is the cheapest layer audit available.

For the gold zone specifically, fact and dimension nodes carry the grain sentence in their description, which is the single most useful thing to have on screen during a modeling review. When the models live in a dbt project, connect the repository and the diagram plus its architecture.md regenerate from the branch on a daily sync, so the picture matches the models rather than the intention.

Two statements about the same table, both true

  prod.gold.fct_subscription_events

  medallion says      gold: consumers may build on it;
                      rebuildable from silver alone
  dimensional says    transaction fact, grain = one row
                      per subscription per state change;
                      measures additive at that grain

  Neither statement implies the other. A gold table with
  no grain sentence has satisfied the first and skipped
  the second, which is what a folder full of marts is.

• Medallion architecture explained
• Kimball dimensional modeling
• Data lakehouse architecture
• How to document a lakehouse
• Unity Catalog structure