Data Vault
Data Vault is a data warehouse modeling methodology, created by Dan Linstedt, that separates data into Hubs (business keys), Links (relationships), and Satellites (descriptive, time-stamped attributes) to make a warehouse resilient to source-system change.
Overview
Data Vault, developed by Dan Linstedt, is designed for the layer between raw source system extracts and a business-facing dimensional model. Its goal is auditability, historical traceability, and tolerance for source systems changing over time — properties that matter most in large, multi-source enterprise warehouses. It decomposes data into three table types:
- Hubs store a list of unique business/natural keys for a core entity (e.g., every distinct
customer_idever seen), plus load metadata. Hubs almost never change once a key is loaded. - Links record relationships between hubs (e.g., a specific customer placed a specific order), modeling many-to-many relationships directly.
- Satellites hold the descriptive, time-varying attributes for a hub or link (name, address, status), each row time-stamped so the full history of every attribute change is preserved by simply inserting new satellite rows — no updates needed.
Example
Copy code
CREATE TABLE hub_customer (
customer_hash_key VARCHAR PRIMARY KEY, -- hash of the business key
customer_id VARCHAR, -- natural/business key
load_date TIMESTAMP,
record_source VARCHAR
);
CREATE TABLE sat_customer_details (
customer_hash_key VARCHAR REFERENCES hub_customer(customer_hash_key),
load_date TIMESTAMP,
customer_name VARCHAR,
email VARCHAR,
hash_diff VARCHAR, -- hash of the attributes, to detect changes
PRIMARY KEY (customer_hash_key, load_date)
);
CREATE TABLE link_customer_order (
link_hash_key VARCHAR PRIMARY KEY,
customer_hash_key VARCHAR REFERENCES hub_customer(customer_hash_key),
order_hash_key VARCHAR,
load_date TIMESTAMP
);
Because inserts, not updates, drive nearly all loading, Data Vault tables are highly parallelizable to load and naturally preserve full history — but the model is verbose and rarely queried directly by business users. Most Data Vault warehouses build a Kimball-style dimensional layer (facts and dimensions) on top for reporting.
DuckDB angle
DuckDB's fast hashing and joins make it a reasonable engine for computing hash keys and hash-diffs during Data Vault loads, and for building the downstream dimensional views business users actually query, though Data Vault's insert-heavy, highly-normalized pattern is more commonly run in an orchestrated pipeline than queried ad hoc.
Related terms
Dimensional modeling is a data warehouse design methodology, developed by Ralph Kimball, that organizes data into fact tables (measures) and dimension tables (descriptive context) optimized for business-user querying.
Natural key →A natural key is an identifier that comes from real-world business data — like an email address, SSN, or product SKU — as opposed to a surrogate key generated purely for database use.
Surrogate key →A surrogate key is a system-generated identifier — typically a sequential integer or UUID — assigned to a row that has no business meaning of its own, used as the primary key in dimension and fact tables.
Slowly changing dimensions (SCD) →Slowly changing dimensions (SCD) are techniques for handling changes to dimension attributes over time — such as a customer moving to a new region — while preserving or overwriting historical values as needed.
foreign key →A foreign key links one table to another by referencing its primary key. Learn how foreign keys enforce referential integrity, with SQL syntax, composite key examples, and data warehousing use cases.
Semantic layer →A semantic layer is a layer between raw data and end users that defines business metrics, dimensions, and relationships once, so that different tools and teams query consistent, agreed-upon definitions instead of re-deriving them independently.
FAQS
Hubs store unique business keys for core entities. Links record relationships between hubs. Satellites store the time-stamped, descriptive attributes for a hub or link, preserving full history through inserts rather than updates.
No. Data Vault is typically used as an intermediate, highly-auditable layer between raw source data and a business-facing model. Most Data Vault warehouses still build Kimball-style star schemas on top for reporting and BI.
