glossary4 min read

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.

LayerContentsQuality
BronzeRaw ingested data, append-onlySource fidelity, no cleanup
SilverCleaned, deduped, conformedBusiness entities, type-safe
GoldCurated facts, dimensions, metricsBI-ready, SLAs apply
(Optional) PlatinumML feature tablesEngineered 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