The Medallion Architecture Guide: Bronze, Silver, Gold

2026-05-12

What Is Medallion Architecture?

Medallion architecture organizes data in a lakehouse or warehouse into layered zones—typically bronze (raw), silver (cleansed and conformed), and gold (business-ready aggregates and marts). Each layer has a clear contract: what is allowed to change, who owns quality, and how downstream consumers depend on it.

The pattern reduces chaos when many sources feed analytics and AI. Raw history stays recoverable in bronze; silver reconciles IDs, types, and slowly changing dimensions; gold exposes stable metrics for BI and ML features.

Teams adopt medallion models because they separate ingestion concerns from semantic modeling, making pipelines easier to test, document, and evolve without breaking every dashboard at once.

Bronze Layer

The bronze layer stores data as close to the source as practical: append-only or lightly typed tables, often partitioned by ingest time. The goal is fidelity and auditability—if a field appeared in the API, you can replay or reprocess later.

Bronze is not “dirty data forever”; it is a controlled landing zone with minimal business rules so pipelines stay fast and resilient to upstream quirks. Heavy interpretation waits for silver.

Good bronze hygiene includes metadata (load timestamps, source system, batch IDs) so you can trace rows back to extraction jobs and debug discrepancies.

Silver Layer

Silver applies cleansing, standardization, deduplication, and joins across sources to produce conformed entities—customers, products, orders—with consistent keys and types. This is where data quality rules and SCD patterns usually live.

Silver models are still reusable building blocks: they feed multiple gold marts without copying logic everywhere. Tests (uniqueness, referential integrity) belong here so issues surface before executives see wrong KPIs.

Silver work is where teams spend significant SQL and dbt effort unless automation assists with model generation from discovered schemas.

Gold Layer

Gold layers present domain-specific datasets optimized for consumption: revenue marts, funnel analysis, cohort tables, or feature stores. Grain and definitions match business language—monthly ARR, churn rate, active users—so BI and AI consumers trust the numbers.

Gold should be thin on surprises: breaking changes require communication and versioning. Many teams expose gold through semantic layers or metric definitions tied to these tables.

Performance tuning (sort keys, clustering, materializations) is common at gold because query patterns are predictable and SLA-sensitive.

How Skippr Automates It

Skippr accelerates the path from raw ingestion to modeled layers by combining automated schema discovery, cleansing, and AI-assisted dbt generation. Instead of hand-authoring every bronze and silver table, you guide the system and review outputs.

That means faster time to silver-quality entities and gold-ready marts, with less copy-paste SQL. Skippr’s focus on reliable delivery and cleansing reduces the operational tax that often stalls medallion rollouts.

Whether you store bronze in object storage or warehouse tables, Skippr helps keep upstream syncs dependable so downstream layers are not fighting bad loads.

Best Practices

Document layer contracts: naming, ownership, SLAs, and allowed transformations. Use idempotent loads and clear incremental strategies so bronze replays do not duplicate silver. Test silver aggressively; gold should mostly compose tested building blocks.

Avoid business logic leaking into bronze; keep it technical. Push cross-source truth to silver; reserve executive metrics for gold. Version breaking changes and communicate to downstream teams.

With Skippr, you can enforce consistent ingestion and cleansing early, making medallion layers easier to maintain as sources multiply—exactly when architecture discipline pays off most.