What Is Medallion Architecture? Bronze, Silver, Gold
What Is Medallion Architecture? Bronze, Silver, Gold
Medallion architecture is a lakehouse design pattern that organizes data into three quality tiers: bronze (raw ingested data), silver (cleaned and conformed), and gold (curated business-ready tables). Data flows from bronze → silver → gold with quality improving at each step. Databricks popularized the pattern but it works on any lakehouse or warehouse.
Medallion architecture is the dominant pattern for lakehouse projects in 2026. This guide walks through what each layer does, how data flows between them, and why the three-tier structure has become the default for modern lakehouses.
The pattern is not new — teams have been layering raw, cleaned, and curated tables for decades. Databricks' contribution was naming the layers (bronze, silver, gold) and marketing the pattern as a coherent architecture. The names stuck because they communicate the quality gradient clearly. When an engineer says "we need to add a gold table," everyone knows roughly what they mean, which is genuinely useful.
The Three Medallion Layers
Bronze stores raw ingested data exactly as received — no cleaning, no schema enforcement, just append-only history. Silver applies cleaning, deduplication, type casting, and basic joins to produce conformed entities. Gold contains curated business-ready tables: facts, dimensions, aggregates, and metric tables consumed by BI and ML.
| Layer | Contents | Quality |
|---|---|---|
| Bronze | Raw ingested data, append-only | Source fidelity, no cleanup |
| Silver | Cleaned, deduped, conformed | Business entities, type-safe |
| Gold | Curated facts, dimensions, metrics | BI-ready, SLAs apply |
| (Optional) Platinum | ML feature tables | Engineered for training |
Why Three Layers
Each layer solves a different problem. Bronze preserves raw data for reproducibility. Silver isolates the cleaning logic so it can be rerun when bugs are found. Gold exposes stable, documented tables to consumers. Without the layers, all three concerns mix in one place and every change risks every consumer.
The separation also clarifies ownership. The ingestion team owns bronze. The transformation team owns silver. The analytics or domain team owns gold. Each layer has different tests, different SLAs, and different review processes, matching the different risks at each stage. A bug in gold is visible to executives within hours; a bug in bronze might go unnoticed for weeks. Tiered ownership lets teams calibrate their response to the tier's blast radius.
Bronze Layer Patterns
Bronze is pure ingestion: land raw data with minimal processing. Preserve the source schema as-is, including ugly nested JSON and inconsistent types. Use Delta Lake, Iceberg, or Hudi for the format so you get ACID transactions on the raw tier. Retain bronze indefinitely or until archival policies kick in.
A common bronze pattern is append-only ingestion with a load timestamp on every row. Even late-arriving data lands at its actual event time, with a separate load_ts column for audit. This lets downstream silver layers reprocess bronze any number of times without losing the original ordering. Bronze should also include source metadata — the file name, the ingestion job id, the schema version — because that context is often essential when debugging downstream issues.
Silver Layer Patterns
Silver is where most of the business logic lives that consumers never see directly. It is also the layer most prone to bugs, because joining, deduplicating, and type-casting raw inputs requires dozens of small decisions that can drift over time. Invest heavily in silver layer testing — every silver model should have uniqueness, not-null, and referential integrity tests at minimum.
- •Type casting — strings to dates, numerics, etc
- •Deduplication — handle at-least-once ingestion
- •Null handling — defaults, inference, or explicit markers
- •Joins across sources — link customer IDs across systems
- •Slowly changing dimensions — preserve history where needed
Gold Layer Patterns
Gold is where business logic lives. Fact tables and dimension tables in star schemas. Aggregations for common BI queries. Metric tables for the semantic layer. Gold has SLAs, tests, ownership, and documentation. Everything consumer-facing in the warehouse should live in gold.
For related reading see what is a data lake, data warehouse vs data lake, and how to design a data warehouse.
Medallion in Practice
Most dbt projects already implement a medallion pattern: staging models = silver, intermediate models = silver+, mart models = gold. Raw data lives outside dbt in the bronze tier. The naming differs but the structure is the same. Pick terminology that fits your team and commit.
Automating Medallion
Data Workers pipeline agents manage medallion flows end to end — ingesting to bronze, transforming to silver, curating to gold, and monitoring quality at each tier. Book a demo to see medallion automation in action.
Real-World Examples
A financial services firm uses Databricks with Delta Lake to implement a strict medallion structure: bronze holds raw CDC events from mainframe systems, silver joins customer and account entities, and gold serves regulatory reporting. A marketing agency uses Snowflake without the medallion labels, but with a functionally equivalent structure: raw schema, staging schema, and marts schema — same pattern, different names. A gaming studio uses Iceberg on S3 with bronze for raw telemetry, silver for cleaned session data, and gold for live-ops metrics. All three are medallion.
When You Need It
You need formal medallion structure the moment pipelines become hard to reason about. Early on, you can get away with a single transformation layer; as the codebase grows, separating raw, cleaned, and curated becomes essential for testing, ownership, and reproducibility. The transition usually happens somewhere between 20 and 50 active models. Past that point, the lack of layering starts costing more than the discipline of maintaining layers.
Common Misconceptions
Medallion is not Databricks-specific. It works on any lakehouse or warehouse and is already implicit in most well-designed dbt projects. The three-layer count is also not sacred — some teams use four layers, some use two — and the names matter less than the separation of concerns. And medallion is not just for lakes; cloud warehouses benefit from the same structure.
Medallion architecture organizes a lakehouse or warehouse into bronze, silver, and gold layers with rising quality at each tier. It is the dominant pattern for modern lakehouses because the separation makes pipelines reproducible, testable, and maintainable at scale.
Go from data platform to
agentic platform.
With autonomous AI agents working across your entire data stack — MCP-native, open-source, deployed in minutes.
Book a Demo →Related Resources
- Agent-Native Architecture: Why Bolting Agents onto Legacy Pipelines Fails — Bolting AI agents onto legacy data infrastructure amplifies problems. Agent-native architecture d…
- Context Layer Architecture: 5 Patterns for Giving AI Agents Data Understanding — Five architecture patterns for building a context layer: centralized, federated, hybrid, MCP-nati…
- Modern Data Pipeline Architecture: From Batch to Agentic in 2026 — Modern data pipeline architecture in 2026 spans batch, streaming, event-driven, and the newest pa…
- The Data Lakehouse Architecture Guide: Iceberg, Delta, and Hudi — The data lakehouse combines data lake flexibility with warehouse performance. This guide covers I…
- Context Engine Modular Plugin Architecture — Context Engine Modular Plugin Architecture