What is Medallion Architecture?

Medallion architecture is the branding Databricks applied to a very old pattern — raw/staging/marts, or landing/cleansed/curated — and happens to be the most useful three-layer default for any lakehouse or warehouse project in 2026. Bronze = raw source data exactly as it arrived (no transforms, only metadata). Silver = cleaned, deduplicated, conformed entity tables with strong types. Gold = business-ready aggregates, dimensional models, and feature tables that power dashboards and ML. The naming is memorable; the pattern is platform-agnostic — you can implement it with dbt in Snowflake, with Spark on Delta, with Airflow + Iceberg, or with homegrown SQL. The value isn't in the medal names; it's in the discipline of not letting raw ingests go directly to dashboards and not letting business logic leak into data-cleaning jobs.

Why it matters (the failure mode it prevents)

Without medallion-style separation, two pathologies emerge. (1) Dashboards read directly from raw source tables, so a vendor's API schema change silently breaks the CEO dashboard. (2) Business logic gets mixed into cleaning logic, so nobody can tell whether "active customer" means one thing in Marketing's definition and another in Sales's. Bronze/Silver/Gold forces a physical and logical boundary: Bronze preserves history (replayable source of truth), Silver standardizes entities (shared semantics across the org), Gold encodes business rules (owned by domain teams). Each layer has a different owner, different SLA, different refresh cadence.

Field story

A retail client had grown their dbt project from 20 to 420 models over 18 months with no layering discipline — models directly on raw CDC tables, joins across 8 sources per model, business metrics defined inconsistently across 6 different models. A tax-code change in the source ERP broke 38 downstream dashboards overnight because no staging layer absorbed the schema drift. We refactored into strict medallion: 120 Bronze (raw CDC snapshots, 1:1 with sources), 180 Silver (deduplicated, conformed entities: customer, product, order, transaction), 120 Gold (department-owned marts with documented metrics). Source schema changes now break only 1-3 Silver models (usually auto-healed by dbt contracts); Gold dashboards are insulated. Time to add a new source dropped from 2 weeks to 3 days. The refactor took 6 months; the ongoing velocity gain was worth 2x that investment.

The Medallion Architecture (also called Multi-Hop Architecture) is the most popular design pattern for organizing data in a Data Lakehouse. Popularized by Databricks, it divides your data pipeline into three distinct quality layers:

The Three Layers

🥉 Bronze Layer (Raw)

The landing zone for raw, unprocessed data:

• What goes here: Exact copies of source data — JSON payloads, CDC logs, CSV dumps
• Format: Usually stored as-is, with added metadata (ingestion timestamp, source system)
• Purpose: Single source of truth; you can always replay from bronze
• Example: Raw Salesforce API responses, Kafka event streams, database replication logs

🥈 Silver Layer (Cleansed)

Data that has been validated, deduplicated, and conformedData:

• What happens here: Schema enforcement, null handling, deduplication, type casting
• Format: Strongly typed, partitioned, stored in columnar format (Parquet/Delta)
• Purpose: Enterprise-wide "clean" data that is usable across teams
• Example: A unified customers table combining Salesforce + Stripe + internal DB records

🥇 Gold Layer (Business-Ready)

Aggregated, enriched data tailored for specific business use cases:

• What goes here: Business metrics, KPI tables, feature stores, ML training sets
• Format: Star/snowflake schemas optimized for BI tools
• Purpose: Powers dashboards, reports, and ML models directly
• Example: daily_revenue_by_region, customer_lifetime_value, churn_predictions

Why It Works

Source Systems → [Bronze] → [Silver] → [Gold] → BI / ML
                   Raw        Clean      Aggregated
                   Append     Validated   Business Logic
                   Replay     Conformed   Star Schema

Key Benefits

• Incremental Processing: Each layer only processes what changed
• Debuggability: When something breaks, trace it back through the layers
• Reusability: Silver layer serves multiple Gold-layer consumers
• Governance: Apply access controls at the appropriate layer

Medallion Architecture Tools

Anti-Patterns to Avoid

1. Skipping Silver: Going directly from Bronze to Gold creates fragile pipelines
2. Too Many Layers: Some teams add Platinum, Diamond — keep it simple
3. No Schema Enforcement: Silver should enforce schemas strictly
4. Ignoring Bronze Retention: Bronze is your backup; don't delete it too aggressively

Medallion architecture pitfalls that undercut its value:

• Bronze as a dumping ground. Bronze should be exact copies of source data with only added metadata (ingest timestamp, source system). Any transformation in Bronze defeats the purpose — you lose the ability to replay from source. Enforce "no transforms in Bronze" via code review.
• Silver doing double duty as Gold. Teams putting business-specific aggregates in Silver creates conflicts — different departments need different metrics. Silver is entity-level and org-wide; Gold is use-case and department-specific.
• Over-layering every table. Not every table needs all three layers — reference data (country codes, timezone lookups) can live directly in Silver or even Gold. Dogmatic three-layer rules for every table waste pipeline cost.
• Under-layering business logic. Business metrics defined in multiple Gold models drift over time — "active customer" means 3 different things. Use a semantic layer (dbt semantic layer, Cube, AtScale) or single-source Gold metric tables to enforce consistency.
• Ignoring the cost of Silver cleaning. Cleansing operations (deduplication, type casting, null handling) on terabytes of data are expensive. Cluster/partition Silver tables by natural keys and only re-process changed partitions.
• Cascading reprocessing storms. A schema change in Bronze triggers full reruns of Silver and Gold — with no incremental strategy, this is a 4-hour pipeline burn. Use incremental materializations and upstream change detection (dbt state-aware, Dagster asset staleness).
• No SLA per layer. Bronze, Silver, Gold have fundamentally different freshness needs. Bronze may be hourly, Silver nightly, Gold weekly — or Bronze real-time, Silver 15-minute micro-batches, Gold hourly. Decide SLA per domain, document it, and monitor it.
• Medallion ≠ data mesh. Medallion is about vertical data quality layers; data mesh is about horizontal domain ownership. You can combine them (each domain has its own Bronze/Silver/Gold), but they solve different problems. Don't use "we have medallion" as a substitute for domain ownership.
• Confusing Bronze with staging (dbt) or landing (ADF). Dbt's "staging" layer typically does light cleaning (renaming, casting) — that's closer to a thin Silver than Bronze. Decide your mapping explicitly: raw → staging → intermediate → marts, or Bronze → Silver → Gold. Pick one vocabulary per project.
• Gold tables without documentation. Gold is where business people land. An undocumented Gold table with columns named m1, m2, pct_chg destroys trust. Every Gold model should have a description, tests, and owner — enforce via CI.