The layer map
Switch the view, then click a layer to see its purpose, its tables, the SQL that builds them and sample rows. The data is a fictional Swiss wholesaler supplying cafés, hotels and care homes. It has 13 customers, 12 products and 42 orders, delivered in three batches (5 Jan, 2 Mar and 4 May 2026). Some customers move, prices change and order status moves on, so the satellites show history.
Hash keys and hashdiffs
Hash key
Every business key becomes an MD5 hash in staging: trim it, uppercase it, hash it. Link keys hash the combined business keys with a || separator. Because the hash depends only on the key, any loader can compute it in parallel, with no lookups against sequences.
md5(upper(trim(sku)))
md5(concat_ws('||', upper(trim(order_no)),
upper(trim(sku))))
Try it live: → …
The dataset contains one deliberately messy SKU, ' p-1xx ', in an order line. It still lands on the same hub row.
Hashdiff
A hashdiff is an MD5 over all descriptive attributes of a satellite. When a batch arrives, the loader compares each row's hashdiff with the latest one in the satellite. Same hash: skip. Different: insert a new row. Nothing is ever updated or deleted.
md5(concat_ws('||', upper(trim(name)), upper(trim(city)),
upper(trim(segment)), credit_limit::VARCHAR))
Customers arrive as a full snapshot each batch: 37 staging rows, but only 18 satellite rows, because unchanged rows are dropped. Query 2 in the console shows the decision row by row.
The building blocks
Staging
The source data as delivered, plus a load date, a record source and computed hash keys and hashdiffs. No business rules.
Hub
One row per unique business key (customer number, SKU, order number), with the hash key, first load date and record source. Nothing else.
Link
One row per unique relationship between hubs, such as order↔customer or order↔product. Links are always many-to-many, so a change in cardinality never forces a remodel.
Satellite
Descriptive attributes and their history, keyed by parent hash key and load date. Insert-only. Split satellites by source or by rate of change.
PIT table
Point-in-time: for each key and snapshot date, it stores which satellite row was valid. Marts then join on equality instead of searching date ranges.
Bridge
Pre-joins a path of links and hubs (here order line → order → customer, plus product) so marts don't repeat the multi-way join.
Information mart
Star schema for users and BI tools: dimensions from hub + satellite, facts from links + link satellites. Usually views or tables that can be rebuilt at any time from the vault. Compare the Kimball star schema demo.
How teams actually map it
Medallion names the refinement stages. Data Vault says how to model them. They don't conflict, but there's no single standard mapping. Common variants:
Mapping used here
Bronze = landing + staging. Silver = raw vault + business vault. Gold = information marts. This is the most common pairing, and Databricks describes it this way too.
Raw vault in Bronze
Some teams treat the raw vault as part of Bronze (sometimes called "Bronze+"), because no business rules have been applied yet. Silver then holds only the business vault.
Business vault in Gold
Others put PIT tables, bridges and computed satellites in Gold, next to the marts, because they exist mainly to serve them.
Skip the vault
For a few sources that rarely change, many teams go straight from Bronze to cleaned Silver tables. A vault pays off when you have many sources, frequent schema change, or audit and history requirements.
SQL console
DuckDB-WASM loads all 18 tables from Parquet into your browser. Pick an example or write your own query. Ctrl/Cmd + Enter runs it.
Tooling: don't hand-write the vault
Hubs, links and satellites follow fixed patterns, so they are usually generated from metadata.
AutomateDV
dbt package (formerly dbtvault) by Datavault UK. Macros such as stage, hub, link, sat, pit, bridge and eff_sat. Supports Snowflake, Databricks, BigQuery, SQL Server and Postgres.
datavault4dbt
dbt package by Scalefree, built around Data Vault 2.0 as Scalefree teaches it. It covers staging with hashing and ghost records, hubs, links, satellites (v0/v1 views), PITs, snapshot control and reference tables, on Snowflake, BigQuery, Exasol, Redshift, Synapse, Postgres and more.
Marts on top
Gold marts are ordinary dbt models over the vault, often built from PIT and bridge tables. Each package documents its mart patterns. Without dbt, the SQL in this page's layer map shows the same patterns by hand.
This demo uses MD5 and full-snapshot batch loads to keep things readable. Real projects often use SHA-1 or SHA-256, add ghost records (zero keys) and effectivity satellites for links, and load in parallel from many sources.