Data Vault 2.0 is a data warehouse modeling methodology designed for agility, auditability, and parallel loading. Where Kimball dimensional modeling optimizes for query simplicity and end-user analytics, Data Vault optimizes for the integration layer -- the place where data from many source systems comes together before being shaped for reporting. It is an increasingly popular choice for organizations that need to ingest data from dozens or hundreds of sources, track lineage precisely, and adapt quickly when sources change.
The Three Core Building Blocks
Data Vault models are built from three types of tables, each with a specific role.
Hubs represent core business entities -- the things your organization tracks over time. A hub for customers, a hub for products, a hub for orders. Each hub contains a hash key (derived from the business key), the business key itself, a load timestamp, and a record source. Hubs are intentionally minimal. They do not store descriptive attributes, and they never change once a row is inserted.
Links represent relationships between hubs. A link connecting the customer hub to the order hub captures the fact that a particular customer placed a particular order. Links contain hash keys referencing the related hubs, a load timestamp, and a record source. Like hubs, links are insert-only -- once a relationship is recorded, the row stays.
Satellites store the descriptive attributes and their change history. Each satellite is attached to either a hub or a link and contains the attributes that describe that entity or relationship at a point in time. A customer satellite might hold name, email, segment, and region. When any attribute changes, a new satellite row is inserted with a new load timestamp. The previous row remains untouched, creating a complete audit trail.
Why Three Table Types?
The separation into hubs, links, and satellites solves several problems that plague other modeling approaches.
Parallel loading. Because hubs, links, and satellites are independent tables, they can be loaded concurrently by separate ETL processes. Adding a new source system means adding new satellite tables -- you never need to alter existing hubs or links.
Full auditability. Every row in every table has a load timestamp and record source. You can always answer "where did this data come from, and when was it loaded?" Satellites preserve every version of every attribute, so you can reconstruct the state of any entity at any point in time.
Resilience to change. When a source system adds new fields, you add a new satellite or extend an existing one. When a new relationship emerges, you add a link. Hubs are stable because business entities rarely disappear. This insert-only, additive design means the model grows without breaking existing structures.
How Data Vault Differs from Dimensional Modeling
The most important distinction is purpose. Dimensional models (star schemas) are designed for direct querying by analysts and BI tools. They prioritize simplicity and performance at the reporting layer. Data Vault models are designed for the integration and historization layer -- they prioritize flexibility, auditability, and ease of loading.
In practice, many organizations use both. Source data flows into a Data Vault integration layer, where it is cleansed, historized, and consolidated. Downstream star schemas are then derived from the vault for reporting and dashboarding. This hybrid approach gives you the loading agility of Data Vault and the query simplicity of star schemas.
Another key difference is normalization. Star schemas deliberately denormalize dimension attributes into flat tables. Data Vault pushes further toward normalization -- separating entities (hubs), relationships (links), and attributes (satellites) into distinct tables. This normalization makes loading and change management straightforward but makes direct querying more complex, which is why the reporting layer usually sits on top as a separate dimensional model.
When to Choose Data Vault
Data Vault shines in specific scenarios.
Many source systems. If you are integrating data from ten, fifty, or a hundred different sources, Data Vault's hub-link-satellite structure handles the complexity without requiring a unified upfront schema design.
Regulatory or audit requirements. Industries like finance, healthcare, and government often require full data lineage and point-in-time reconstruction. Data Vault's insert-only design and record source tracking provide this natively.
Rapidly changing source schemas. When source systems evolve frequently -- new fields, renamed columns, restructured relationships -- Data Vault absorbs these changes by adding satellites rather than altering existing tables.
Large data engineering teams. Because hubs, links, and satellites can be loaded independently, multiple teams can work in parallel without coordination bottlenecks.
Data Vault is less appropriate when the primary need is fast, simple analytical queries and the source landscape is stable. In those cases, building star schemas directly from source data may be more practical. For a broader comparison of warehouse architecture philosophies, see Kimball vs Inmon, which covers how these approaches relate to each other and where Data Vault fits in the landscape.
Getting Started
If you are evaluating Data Vault for your organization, start with a small proof of concept. Pick two or three source systems that share common business entities (customers, products, transactions), model the hubs and links for those entities, and attach satellites for the attributes each source provides. This exercise reveals both the strengths of the approach -- parallel loading, clear lineage -- and the cost: more tables, more joins, and the need for a separate reporting layer on top.