What is Data Vault 2.0 modeling and how does it compare to Kimball Dimensional Modeling?

Data Vault 2.0 is an enterprise‑scale modeling method that captures raw business events in Hubs, Links, and Satellites, while Kimball’s dimensional model builds star schemas for analytical consumption.

Implementation steps for a Data Vault 2.0 model
1. Identify business keys → create a Hub table for each unique key.
2. Determine many‑to‑many relationships → model each as a Link table.
3. Capture descriptive attributes and change history → add one or more Satellite tables per Hub/Link.
4. Apply hash‑diff keys (e.g., SHA‑256) to enforce immutability and enable parallel loading.
5. Load using ELT: stage raw data in a landing zone (e.g., Snowflake RAW_DB), then INSERT into Hubs/Links/Satellites with MERGE for de‑duplication.
6. Build downstream star schemas (Data Marts) by joining Hubs, Links, and Satellites as needed.

Sample DDL (Snowflake SQL)

-- Hub for Customer
CREATE TABLE HUB_CUSTOMER (
    CUSTOMER_HASHKEY   BINARY(32)   NOT NULL,
    CUSTOMER_ID        VARCHAR(50)  NOT NULL,
    LOAD_DATETIME      TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP,
    RECORD_SOURCE      VARCHAR(100),
    CONSTRAINT PK_HUB_CUSTOMER PRIMARY KEY (CUSTOMER_HASHKEY)
);

-- Link between Customer and Order
CREATE TABLE LINK_CUST_ORDER (
    LINK_HASHKEY       BINARY(32)   NOT NULL,
    CUSTOMER_HASHKEY   BINARY(32)   NOT NULL,
    ORDER_HASHKEY      BINARY(32)   NOT NULL,
    LOAD_DATETIME      TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT PK_LINK_CUST_ORDER PRIMARY KEY (LINK_HASHKEY)
);

-- Satellite for Customer attributes
CREATE TABLE SAT_CUSTOMER_ATTR (
    HUB_HASHKEY        BINARY(32)   NOT NULL,
    EFFECTIVE_FROM     TIMESTAMP_NTZ NOT NULL,
    EFFECTIVE_TO       TIMESTAMP_NTZ,
    CUSTOMER_NAME      VARCHAR(200),
    CUSTOMER_STATUS    VARCHAR(20),
    LOAD_DATETIME      TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT PK_SAT_CUSTOMER_ATTR PRIMARY KEY (HUB_HASHKEY, EFFECTIVE_FROM)
);

Kimball vs. Data Vault 2.0 (quick comparison)
| Aspect | Kimball Dimensional | Data Vault 2.0 |
|---|---|---|
| Primary goal | Fast query performance | Agility & auditability |
| Structure | Star schema (Fact + Dim) | Hubs, Links, Satellites |
| Change handling | Slowly changing dimensions (type 1/2) | Full historization via hash‑diff satellites |
| Load pattern | ETL (transform before load) | ELT (load raw, transform in warehouse) |
| Scalability | Works well to few‑hundred tables | Designed for thousands of tables and petabyte‑scale lakes |
| Governance | Relies on manual CDC | Built‑in lineage via hash keys |

Decision checklist
- Need 100% auditability and point‑in‑time reconstruction? → Data Vault.
- Primary workload is ad‑hoc analytics on stable dimensions? → Kimball.
- Expect rapid source onboarding and parallel loads? → Data Vault.
- Want a single, well‑understood model for business users? → Kimball.