Data platforms organise data into layers so raw inputs, cleaned data and business-ready tables never get mixed up. This page explains the classic raw / staging / core / marts design, the medallion bronze / silver / gold variant, how they map onto each other, and how to keep layers honest.
Almost every analytical data platform moves data through a series of layers, each with a single responsibility and a clear contract about what it contains. The classic warehouse vocabulary is:
The medallion architecture describes the same idea with quality-level names, and was popularised by Databricks for lakehouses built on Delta Lake. Bronze holds raw ingested data, silver holds cleaned, validated and conformed data, and gold holds business-level aggregates and curated datasets ready for analytics and ML. Because it sits on open table formats with ACID transactions and time travel, each layer is just a set of tables in object storage.
The vocabulary is intentionally coarse: three tiers are easy to explain to non-engineers, and the metal metaphor signals increasing trust. The detailed design for each layer on Databricks is covered in the Medallion Architecture section.
Layering is a separation-of-concerns technique for data:
The two schemes are not competitors; they are different granularities of the same principle. Raw maps to bronze and marts map to gold. The middle is where teams differ: staging is sometimes implemented as views over bronze, sometimes as the first silver tables; core is the heart of silver. Some teams split gold into "shared gold" (conformed facts and dimensions) and per-team "platinum" or sandbox layers. What matters is not the names but that each layer has a written contract: who writes it, what quality checks it passes, who may read it, and whether it keeps history.
Streaming and layers. Layering is not only for nightly batch. In a lakehouse, bronze is often fed continuously by a stream (for example from Kafka or change data capture), silver is updated incrementally with MERGE as new bronze records arrive, and gold aggregates are refreshed on a schedule or as materialised views. The contracts stay the same; only the refresh cadence differs per layer. This is one reason the medallion vocabulary caught on: it describes data quality rather than processing style, so the same picture works for batch, streaming and mixed pipelines. When freshness requirements differ by consumer, it is usually cheaper to make one gold table streaming than to make the whole platform real time.
A minimal end-to-end flow for one source, in warehouse-style SQL (Snowflake syntax for semi-structured access; the same structure works in Spark SQL or BigQuery):
-- Raw / bronze: exact copy with load metadata (never edited).
CREATE TABLE raw.shop_orders (
payload VARIANT, -- or STRING / JSON depending on platform
_source_file STRING,
_loaded_at TIMESTAMP
);
-- Staging: one view per source table; rename, cast, nothing else.
CREATE OR REPLACE VIEW staging.stg_orders AS
SELECT payload:id::INT AS order_id,
payload:customer_id::INT AS customer_id,
payload:total::NUMBER(10,2) AS order_total,
payload:created_at::TIMESTAMP AS ordered_at,
_loaded_at
FROM raw.shop_orders;
-- Core / silver: deduplicated, integrated entities.
CREATE OR REPLACE TABLE core.orders AS
SELECT * FROM staging.stg_orders
QUALIFY ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY _loaded_at DESC) = 1;
-- Mart / gold: shaped for a specific audience.
CREATE OR REPLACE TABLE marts.daily_revenue AS
SELECT CAST(ordered_at AS DATE) AS order_date,
COUNT(*) AS orders,
SUM(order_total) AS revenue
FROM core.orders
GROUP BY 1;Each statement has one job. The raw table is never updated. The staging view only renames and casts, so if the source changes its JSON shape, the fix is local. The core table removes duplicates caused by re-delivered files, keeping the latest load per order_id. The mart answers one business question. In practice these steps are managed by a tool such as dbt or Delta Live Tables, which also adds tests between layers and builds the dependency graph.
| Aspect | Raw / Staging / Core / Marts | Bronze / Silver / Gold |
|---|---|---|
| Origin | Data warehousing practice (Inmon, Kimball, later dbt conventions) | Lakehouse practice, popularised by Databricks |
| Granularity | Four or more layers, explicit staging | Three tiers, coarser |
| Typical storage | Warehouse schemas | Delta / Iceberg tables in object storage |
| Core modelling | 3NF, Data Vault or conformed dimensions | Often conformed entities in silver; less prescriptive |
| Strength | Precise contracts per step | Simple to communicate; fits streaming and batch |
| Risk | Too many layers and copies | Silver becomes a vague catch-all |
Choose the vocabulary your platform and team already use. If you are on Databricks, medallion names will match documentation and tooling. If you are on a warehouse with dbt, staging / intermediate / marts is the convention most examples follow.