Medallion architecture: bronze, silver, gold

Medallion architecture is a pattern for organising lakehouse tables into three layers of rising quality: bronze holds raw data as it arrived, silver holds validated and cleaned records, and gold holds business-ready, usually aggregated tables. The decision rule for exams: raw and replayable means bronze, cleaned one-row-per-record means silver, shaped for a report or dashboard means gold. Nothing downstream writes back into an earlier layer.

One order, followed through three layers

This guide uses a single small example to show what each layer does. A retailer receives order events as JSON files, sometimes twice, sometimes with a missing customer, sometimes with test orders.

Bronze: land it, keep it

Databricks describes bronze as raw, unvalidated data kept in its original form, appended incrementally from cloud storage or message buses, with minimal validation. Most fields stay as strings or similar loose types so that a schema change at the source does not drop data. Bronze keeps full history so any later layer can be rebuilt.

CREATE OR REFRESH STREAMING TABLE orders_bronze
AS SELECT *, _metadata.file_path AS source_file, current_timestamp() AS ingested_at
FROM STREAM read_files('/Volumes/main/retail/landing/orders/', format => 'json');

The extra columns (source file, ingest time) are the optional metadata the Databricks page mentions. No cleaning happens here. Intended users are data engineers and audit, not analysts.

Silver: one trustworthy row per order

Silver is where quality is enforced. Per the Databricks documentation it should contain at least one validated, non-aggregated representation of each record. It enforces schema, handles nulls, removes duplicates and deals with late or out-of-order data. Silver is built from bronze (or other silver tables), not from the ingestion step directly.

MERGE INTO orders_silver s
USING (SELECT order_id, CAST(order_ts AS TIMESTAMP) AS order_ts,
              customer_id, CAST(amount AS DECIMAL(12,2)) AS amount
       FROM orders_bronze
       WHERE order_id IS NOT NULL AND is_test = false
       QUALIFY ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY ingested_at DESC) = 1) b
ON s.order_id = b.order_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

Two steps handle the duplicate order. The QUALIFY filter keeps one row per order_id from bronze, which is required: Databricks documents that a MERGE fails when several source rows match the same target row, and duplicates within the source that match nothing are all inserted. The MERGE keyed on order_id then makes the job idempotent: rerunning after a failure updates instead of duplicating. That is why the Delta table matters: MERGE, schema enforcement and time travel are what make a silver layer practical.

Gold: shaped for the question being asked

Gold is refined, business-aligned data, aggregated and often filtered by period or region, and modelled for reporting. Databricks recommends optimising it for query and dashboard speed, and notes that large historical datasets usually stay in silver.

CREATE OR REPLACE TABLE sales_daily_gold AS
SELECT DATE(order_ts) AS order_date, SUM(amount) AS revenue, COUNT(*) AS orders
FROM orders_silver GROUP BY DATE(order_ts);

Analysts, executives and dashboards read gold. A dimensional design usually lives here, as covered in star schema and modelling.

How the three layers differ

In Fabric

Microsoft’s medallion guidance for Fabric calls it the recommended approach and implements it with lakehouses in OneLake. It lists two deployment patterns: every layer as a lakehouse, or bronze and silver as lakehouses with gold as a warehouse. It recommends a separate workspace per layer for governance, shortcuts in bronze when the source is already in OneLake, ADLS Gen2, S3 or Google storage, and Delta tables in silver and gold. Materialized lake views let you declare the silver and gold transformations in SQL instead of building pipelines. The choice of lakehouse or warehouse for each layer is covered in lakehouse vs warehouse, and a gold layer feeds a Direct Lake semantic model well.

Which exams test this

Fabric and Azure Databricks exams (DP-600, DP-700, DP-750) and the Databricks Data Engineer Professional assume the pattern in scenarios without naming it as an objective, so treat it as background there.

How exam questions are built around it

Questions describe a table and ask for its layer, or describe a requirement and ask where the work belongs. The constraint words: “raw”, “as received”, “reprocess” mean bronze; “deduplicated”, “validated”, “conformed” mean silver; “aggregated”, “dashboard”, “KPI” mean gold.

The usual traps: putting cleansing into the ingestion step so raw data is lost; aggregating in bronze; reading analytics straight from bronze; and writing silver directly from ingestion rather than from bronze. A fourth is the duplicate-on-rerun scenario, where the answer is an idempotent MERGE, not a bigger cluster. The pattern is a convention, not an enforced feature, so a question may also ask who uses each layer.

Practice questions

Go deeper

• What is the medallion lakehouse architecture? (Databricks)
• Implement medallion lakehouse architecture in Fabric
• Related topics: batch vs streaming, Spark basics, and the Data Engineer Associate study plan.