Data vault

What is a data vault?

A data vault is a modelling method for a data warehouse. It stores source data historically and auditably, with every business key, relationship, value change, load time, and source system kept in a structured way.

The method was introduced by Dan Linstedt in the early 2000s and later expanded into Data Vault 2.0. The plain-language idea is simple: build a warehouse layer that does not forget where a value came from or what it used to be.

If a customer moves house, the old address is not overwritten. A new version is loaded, with metadata that says when it arrived and from which system. That makes the warehouse easier to audit and reprocess when source systems change.

The three building blocks

A data vault separates business keys, relationships, and descriptive attributes into different table types.

Hub
A hub stores a business key for a core concept: customer number, product code, order number, supplier ID. It keeps the stable identity, plus metadata such as load date and record source. It does not store the customer's name or address.

Link
A link stores a relationship between hubs. Customer 4712 placed order 88041. Product ABC belongs to supplier S12. The link captures the association and its metadata, not the descriptive details.

Satellite
A satellite stores the descriptive attributes and their history. Customer name, address, phone number, status, segment, or marketing preference live in satellites attached to a hub or link. When a value changes, a new satellite row is added.

Splitting the model this way makes changes easier to absorb. A new source can add a new satellite. A new relationship can add a new link. The existing structure does not need to be rewritten each time a source changes shape.

Why teams use a data vault

• Auditability. Every row carries load and source metadata, so teams can trace where a number came from.

• Historisation by default. Changes are added as new records instead of overwriting old values.

• Source changes are easier to absorb. New sources and attributes can be added beside the existing model.

• Parallel loading. Hubs, links, and satellites can often be loaded independently, which helps on large platforms.

These strengths are useful in regulated environments, mergers, many-source integrations, and warehouses where audit trails matter as much as dashboard speed.

Where does it fit in the architecture?

A data vault is usually not the reporting layer. It is built to integrate and preserve data, not to make life easy for a report author.

A common setup is:

1. raw data lands from the sources

2. the raw vault stores keys, relationships, attributes, history, and metadata

3. business rules and helper structures are added in a business vault or curated layer

4. star schemas, data marts, or semantic models are built on top for Power BI and other reporting tools

On a lakehouse, teams often map this to medallion layers: raw data in bronze, vault structures in silver, and dimensional or semantic models in gold. The exact layering differs by platform, but the role is the same: the vault preserves the auditable middle layer, while reporting models serve the business.

Data vault versus dimensional modelling

Dimensional modelling, often associated with Kimball, is built for reporting. Facts, dimensions, and star schemas make business questions fast and readable.

Data vault modelling is built for integration and history. Hubs, links, and satellites make source changes, audit trails, and many-source integration easier.

That means they are not opposites. Many architectures use a data vault in the back end and dimensional marts in the front end. The vault remembers and integrates. The star schema serves reporting.

Data Vault 2.0

Data Vault 2.0 is more than a table pattern. It adds methodology, architecture guidance, automation patterns, hash keys, parallel loading ideas, and working practices for modern platforms.

The practical consequence is that serious vault projects usually need tooling and naming discipline. The load patterns are repetitive. Teams often generate vault tables and jobs instead of hand-writing hundreds of similar objects.

When is a data vault overkill?

A data vault adds many tables. One simple source table may become a hub, several satellites, and links to other hubs. Queries against the vault itself can require long joins. Without automation and strong conventions, the model becomes hard to operate.

For an SME with a few stable sources and ordinary reporting needs, a straightforward warehouse or star schema is often cheaper and easier. Consider a data vault when you have many sources, frequent structural changes, strict audit demands, long history, or a platform team that can automate the patterns.

What to watch out for

It is not a security vault
The name can be misleading. A data vault is not Azure Key Vault and not a password safe. It is a warehouse modelling method.

Report builders should not suffer through the vault
Build reporting-friendly layers on top. The vault is a foundation, not the user interface.

Tooling matters
Hand-built vaults become tedious quickly. Use generation, templates, and clear standards for keys, satellites, load dates, and source metadata.

Do not adopt it for fashion
If a simple star schema solves the problem, use the simple star schema. A vault pays back its complexity only when the audit and change-management benefits are real.