What Is Data Vault? Architecture & Modeling

Data Vault earns its added modeling complexity when an enterprise must integrate many changing source systems while preserving traceable history. It separates integration design from reporting design, so source churn can be absorbed without repeatedly rebuilding the presentation layer.

This post covers what Data Vault is and where it came from, the problem it addresses, how hub, link, and satellite modeling actually works, the architecture layers that surround it, what changed in Data Vault 2.0, a step-by-step walkthrough of building one, and where its benefits stop paying for its added complexity.

What is Data Vault?

Data Vault is a modeling technique, not a product or a specific database. Dan Linstedt began developing it in the 1990s and released it as a public-domain modeling method in 2000. In July 2002, he began a five-part public series that defined Data Vault as "a detail oriented, historical tracking and uniquely linked set of normalized tables that support one or more functional areas of business" (Data Vault Series 1: Data Vault Overview).

The technique models three things separately: a hub holds the unique list of business keys for one concept (a customer number, a product SKU), a link holds the relationships between business keys from one or more hubs, and a satellite holds the descriptive attributes about a hub or link, tracked over time. Raw Vault loading is predominantly insert-oriented: hubs retain observed keys, links retain observed relationships, and satellites add a row when a loaded descriptive state changes. Some physical satellite patterns update an end-date column, so insert-only is a common implementation strategy rather than a rule that applies to every column in every table. That structural split and additive loading pattern are what the rest of this post explains.

Linstedt's original description calls Data Vault a hybrid of 3NF and star-schema techniques, aimed specifically at the enterprise integration and history layer rather than the presentation layer end users usually query directly. Dimensional information marts commonly provide that business-facing query layer. It is worth being precise about that positioning up front, because most of the confusion around Data Vault comes from judging it as if it were meant to be queried the way a star schema is.

Why Data Vault matters

A large enterprise warehouse rarely has one clean source of truth for a business concept. Customer data arrives from a CRM, a billing system, and a support platform, each with its own key format, its own update cadence, and its own idea of what "customer" means. A schema modeled directly for reporting, star or normalized, has to pick a shape up front, and a source system merger, acquisition, or re-platforming can force a rework of tables that already hold production history.

Data Vault's answer is to model the layer where sources get integrated separately from the layer where reports get built, and to make the integration layer itself resilient to change. A hub stores a business key with technical loading metadata, while satellites store successive descriptive states for hubs or links. Adding a new source system therefore generally adds hubs, links, or satellites instead of altering structures that already hold production history. Load timestamps and record-source metadata support traceability and historical reconstruction, subject to the source's capture cadence, late-arriving data, deletion handling, and the vault's effectivity design. Those properties suit banking, insurance, and other regulated environments where auditability matters.

That positioning puts Data Vault in a different slot than Kimball or Inmon rather than in direct competition with them, which is easiest to see side by side:

The table's last row is the important one: Data Vault can supply the integration layer underneath a set of dimensional marts. The same three-tier pattern shows up in general warehouse design, where a Data Vault-modeled core absorbs source-system churn and a set of Kimball-style marts sit on top for the queries analysts actually run. The choice concerns how the integration layer survives change over a decade; dashboard SQL is designed in the presentation layer.

How Data Vault modeling works

Every business concept in a Data Vault model gets decomposed along three questions: what identifies it, what is it related to, and what describes it. Those three questions map directly onto hubs, links, and satellites, and the decomposition is deliberate: each of the three changes at a different rate and for a different reason, so keeping them in separate tables means a change in one does not normally force a rewrite of the others.

A business key rarely changes once assigned. Its relationships change more often, as new associations form between existing entities. Its descriptive attributes change the most, and at different rates for different attribute groups: a customer's shipping address changes far more often than their signup date. Raw Vault loading retains the business keys and relationships it has observed and appends rows for changed descriptive states. Row counts therefore generally grow as history accumulates. Implementations may update physical satellite end dates, and effectivity or status satellites can record whether a key or relationship is current. Business-driven cleansing and consumption-oriented current views usually belong downstream, in the layers covered under Architecture below.

Two identifier mechanics support scalable loading. A deterministic hash key, often an MD5 or SHA-256 digest, can replace a sequence-generated surrogate key on hubs and links. Hubs hash a standardized enterprise or integration business key, while links hash a consistently ordered combination of participating keys. When every loader uses the same semantic key definition and canonicalization rules, it can derive the same key independently and avoid looking up a parent's stored surrogate key before loading. Hash collisions still require an implementation policy. A hash diff fingerprints a standardized satellite payload so the loader can compare it with the latest hash diff for that parent instead of comparing attributes one by one.

-- Hub: unique business keys only, no descriptive attributes
CREATE TABLE hub_customer (
  customer_hk    CHAR(32)   PRIMARY KEY,  -- MD5(canonicalized customer_number)
  customer_number VARCHAR(50) NOT NULL,
  load_date      TIMESTAMP  NOT NULL,
  record_source  VARCHAR(50) NOT NULL
);

-- Satellite: appended descriptive states for that hub
CREATE TABLE sat_customer_details (
  customer_hk    CHAR(32)   NOT NULL REFERENCES hub_customer(customer_hk),
  load_date      TIMESTAMP  NOT NULL,
  hash_diff      CHAR(32)   NOT NULL,
  customer_name  VARCHAR(200),
  customer_email VARCHAR(200),
  record_source  VARCHAR(50) NOT NULL,
  PRIMARY KEY (customer_hk, load_date)
);

The separation works because each table has one narrow responsibility. Deterministic keys let loaders resolve relationships without waiting for sequence assignment, while satellites preserve successive states received from a source. Together, these mechanics turn source changes into targeted additions rather than broad remodels of existing history.

Core components of a Data Vault

Hubs store the distinct list of business keys for one concept. Each row carries the business key, its chosen technical key, a load date, and a record source identifying where it came from. A hub does not hold descriptive attributes or relationships; it provides the stable identity to which links and satellites attach. Integrating occurrences across source systems requires a shared enterprise-key definition rather than matching source-local identifiers by value alone (Linstedt's original Data Vault overview).

Links store relationships between business keys from two or more hubs. The raw model represents them as many-to-many structures, with the loader enforcing narrower source cardinality where needed. In a hash-key design, a link's key is typically computed from a consistently ordered combination of the participating business keys. Linstedt's original description called a link "a physical representation of a many-to-many 3NF relationship." A raw link contains the participating keys and technical metadata; descriptive context about the relationship belongs in a satellite attached to the link.

Satellites hold the time-variant descriptive attributes for a hub or a link, with one parent per standard satellite. Each changed state received from a source is stored as a separate row. Implementations may store a physical end date on the previous row or derive that end date in a view. Multiple satellites commonly hang off the same hub, split by rate of change or by source system, so that a fast-changing attribute group does not force history to be duplicated for a slow-changing one.

Metadata and query-performance structures round out the core set. Every hub, link, and satellite row carries a load date and a record source for lineage and debugging. Reference tables hold shared, largely static lookup values (country codes, status codes) that would otherwise be duplicated across satellites. Point-in-time (PIT) structures identify the applicable satellite records for selected snapshot times, so a query can avoid resolving several independent time-variant joins on every execution. Bridge structures collect keys across commonly traversed hubs and links to simplify multi-join paths, especially in multi-tier hierarchies. Either structure may be materialized or implemented as a view (Data Vault Alliance reference architecture). Both exist because the raw vault is optimized for integration and history rather than convenient analyst-facing queries, which the Architecture and Challenges sections below return to.

Data Vault architecture explained

A Data Vault deployment is usually organized into layers, each with a distinct job. A staging layer receives data from source systems and applies technical preparation, such as consistent typing and key canonicalization, without historizing anything itself. The raw vault, built from hubs, links, and satellites, is the central integration and history layer. It loads source records with lineage metadata and applies only hard rules needed to preserve source grain and metadata. It excludes soft, contextual business rules, which keeps the received data available for later interpretation.

Where needed, a business vault built from the same hub, link, and satellite structures applies soft rules: business-driven matching, mastering and survivorship, computed or derived satellites, and aggregations. Soft-rule outputs can be recalculated without rewriting the raw history underneath, which is the point of keeping them in a separate layer from hard rules (Data Vault Alliance on hard and soft rules). When no soft-rule layer is needed, information-delivery views or marts can be built directly from raw vault data.

Information marts are the delivery layer: dimensional, typically Kimball-style star schemas, or other purpose-built views, that BI tools and analysts query. This is the layer readers usually interact with; the raw and business vault layers exist to make what lands here trustworthy and reproducible from source rather than to serve as presentation models themselves.

The raw vault's shape is already close to a graph: a hub resembles a node type, a binary link resembles an edge type, and satellites hold time-variant context about either one. PuppyGraph can define a graph schema over these tables, using hub hash keys as node identifiers and the hub-reference columns in binary link tables as edge endpoints, then run openCypher or Gremlin traversals across the vault in place. A link involving more than two hubs must instead be represented as a node or as multiple derived edges because property-graph edges are binary. On PuppyGraph's default direct-query path, newly landed vault tables become queryable after a user maps them into the graph schema. This can avoid building a bridge or graph-specific mart solely for a current multi-hop relationship query, although point-in-time satellite resolution and mart-level business logic still require explicit modeling.

Data Vault 2.0: What's new?

Linstedt announced Data Vault 2.0 in July 2012. The approach was documented in Linstedt and Olschimke's 2015 Morgan Kaufmann book, Building a Scalable Data Warehouse with Data Vault 2.0. One prominent implementation change was the use of deterministic hash keys in place of sequence-generated surrogate keys. Hash keys are optional in the Data Vault 2.0 modeling standard; sequence and natural-business-key designs remain supported.

With generated surrogate keys, a link or satellite loader must obtain the parent's stored key, which conventionally creates load-order dependencies. Deterministic hash keys calculated in staging from consistently normalized business keys remove that parent-key lookup, allowing hubs, links, and satellites to load concurrently when orchestration and referential-integrity settings permit. Incremental satellite loads may still inspect their own target history to decide whether a descriptive state changed (AutomateDV loading guidance).

Data Vault 2.0 expanded the original model-centric approach into a broader standard covering architecture, implementation, and an explicit delivery methodology based partly on Disciplined Agile. It also codified the hard-rule and soft-rule distinction and extended the model and architecture to semi-structured and unstructured data and NoSQL environments alongside relational systems (Data Vault Alliance on Agile methodology). None of this displaces the original hub-link-satellite pattern. Data Vault 2.0 extends those structural ideas with a broader delivery system and additional implementation options.

Building a Data Vault model step by step

Start with the model itself.

Identify business keys. Start from the concepts the business actually operates on, customer number, order ID, product SKU, not from any single source system's table design. A business key should be stable and meaningful independent of which application currently stores it.

Model the hubs. One hub per business concept, holding the business key, its chosen technical key, load date, and record source. Resist the urge to add descriptive columns here; anything beyond the key and loading metadata belongs in a satellite.

Model the links. For every relationship between business keys that the business cares about (a customer placing an order, a product appearing on an order), create a link containing the participating keys. In a hash-key design, derive its key from a consistently ordered and canonicalized combination of those business keys.

Model the satellites. Attach one or more satellites to each hub or link, grouping attributes by how often they change and, often, by which source system supplies them. A customer hub commonly gets separate satellites for demographic details versus, say, marketing preferences, since the two change on different schedules.

Then build the loading and delivery path.

Load staging, then the raw vault. Land source data with minimal transformation, then load hubs, links, and satellites in the order required by the chosen key strategy and referential-integrity design. Deterministic hash keys can remove parent-key lookup dependencies and allow more of this work to run concurrently.

Layer in business rules and marts. Apply soft rules in an optional business vault, then build the information marts, typically dimensional, that analysts and BI tools query. Add PIT and bridge tables where a mart's query pattern would otherwise require repeatedly resolving the same multi-satellite or multi-hop join.

Benefits of using Data Vault

Auditability. Raw vaults retain observed business keys, relationships, successive descriptive states, load timestamps, and record-source metadata. That record supports lineage and historical reconstruction, subject to capture cadence, late-arriving data, deletion handling, and effectivity design. These properties suit regulated environments where teams must explain what a source delivered and when (Data Vault Alliance reference architecture).

Parallel loading. Deterministic hash keys remove parent-key lookup dependencies, allowing hubs, links, and satellites for a batch to load concurrently when the orchestration and referential-integrity design permit it.

Resilience to source-system change. Adding a new source system typically means adding new hubs, links, or satellites, not altering ones that already hold production history. That additive property is what lets a warehouse absorb an acquisition, a re-platformed CRM, or a new regional source system without a disruptive remodel of tables already in use.

Scalability across many sources. The same hub-link-satellite pattern repeats uniformly regardless of how many source systems feed a concept, which keeps the modeling problem tractable even when many systems all describe the same customer or product differently.

Challenges and limitations of Data Vault

Table count. A Data Vault generally uses more physical tables than a dimensional model because it separates business keys, relationships, and descriptive attributes into hubs, links, and satellites, often splitting satellites further by source or rate of change (a comparative industry case study).

Storage overhead. Retaining successive descriptive states stores historical rows that a current-state-only model omits. Load dates, record-source values, and technical keys add further metadata to satellite rows. Retention, legal deletion, and physical compaction remain implementation choices.

Automation burden. Hand-building the repeated DDL and load patterns for hubs, links, and satellites creates repetitive work and consistency risk. Code generation can reduce that work, but a team must still select, govern, and maintain the tooling and templates that encode its naming, hashing, metadata, and loading rules.

Consumption complexity. The raw vault is an integration and history layer, not a presentation model. Analyst-facing questions against hubs, links, and satellites can require several independent, differently timed joins. PIT structures, bridge structures, and information marts simplify recurring access patterns; direct queries remain possible when their complexity and performance are acceptable.

Learning curve. The three core constructs are simple individually, but applying the hard-rule and soft-rule split correctly, and building the PIT, bridge, and mart layers needed for efficient consumption, takes real ramp-up time. It is generally not the right first warehouse for a small team without an existing data engineering practice.

Conclusion

Data Vault earns its complexity in a specific setting: many source systems, a long time horizon, and a real audit requirement, where the cost of remodeling an integration layer every time a source changes is higher than the cost of maintaining more tables. Its hub-link-satellite split, append-oriented history, and support for deterministic keys all address that setting. They do not make it a general-purpose replacement for Kimball's dimensional marts or Inmon's normalized core; in practice, Data Vault usually sits underneath a presentation layer rather than replacing one. Outside that setting, a team without many integrating sources or a strong history and traceability requirement usually gets more value from a star schema it can build once and query directly.

Try the forever-free PuppyGraph Developer Edition and book a demo with the team to see how openCypher and Gremlin queries traverse warehouse and lakehouse tables, with no graph-specific ETL, mapping raw-vault hubs and binary links into a graph for multi-hop relationship queries.