---
title: "Data Vault"
description: "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."
canonical: "https://motherduck.com/glossary/data-vault/"
related:
  - title: "DuckLake Architecture Deep Dive"
    url: "https://motherduck.com/blog/ducklake-architecture-deep-dive/"
  - title: "Data Warehousing Overview | MotherDuck Docs"
    url: "https://motherduck.com/docs/getting-started/data-warehouse/"
  - title: "From Data Lake to Lakehouse: Can DuckDB be the best portable catalog?"
    url: "https://motherduck.com/blog/from-data-lake-to-lakehouse-duckdb-portable-catalog/"
gated_asset:
  title: "DuckLake on MotherDuck"
  url: "https://motherduck.com/product/ducklake/"
---

# 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_id` ever 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

```sql
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.