Databricks Medallion Architecture

Bronze: keep the evidence

Medallion architecture organizes data into progressively refined layers. Bronze preserves source data and ingestion context; silver validates and cleans records; gold shapes data for business consumption. It is a design pattern, not a requirement to make three copies of every table.

Start with a reason for each layer. A name is not a quality guarantee.

Follow one order through the system

Take a fictional order feed. A source resends order 104 with a corrected amount. Bronze retains what arrived and when. Silver applies an explicit rule for which version is current. Gold aggregates the accepted orders for reporting. The key design question is not “which colour?” but “what does one row represent?”

Write down the contract

For this example, the silver contract could require one current row per order_id, a valid event timestamp, and a nonnegative amount. Invalid rows need an explicit destination and an explanation. The gold contract must define currency, time zone, cancellation handling, and whether revenue reflects order time or payment time. These are business decisions; the storage format cannot make them for you.

-- Illustrative quality check before publishing
SELECT order_id, COUNT(*) AS row_count
FROM silver.orders_current
GROUP BY order_id
HAVING COUNT(*) > 1;

This query checks a proposed uniqueness rule. Returning zero rows does not prove the table is correct: separately test missing keys, invalid amounts, and the agreed freshness target.

Plan for correction, not just the happy path

Suppose a currency conversion rule was wrong for a week. Retained source evidence makes it possible to recompute the affected records. A clear silver grain tells you what to replace. A defined gold dependency tells you which reports need refreshing. Document the replay window and retention period together; you cannot replay data you no longer retain.

Good layers make a correction explainable, bounded, and repeatable.