What problem does data vault modelling solve, and when is its complexity justified?
Show the full answer Hide the answer
The problem it solves
Integrating many source systems whose schemas change independently, while retaining a complete auditable history.
It separates business keys (hubs), relationships (links) and descriptive attributes (satellites). Because attributes are isolated in satellites with load timestamps, a source schema change adds a satellite rather than altering existing structures — so the model is additive under change, which is its central property.
And because everything is retained with load metadata, the history is complete and auditable: what was known, from which source, at what time.
When the complexity is justified
- Many source systems — tens rather than a few — with independent change cadences.
- A regulatory or audit requirement for complete lineage and history: what did we know, from where, when.
- A long-lived integration layer expected to outlast its sources.
- Frequent source changes that would otherwise force repeated remodelling.
When it is not
For a small number of stable sources feeding business intelligence, it is substantial complexity for little benefit. The join count to answer a simple question is high, the model is not understandable by analysts, and a dimensional model would serve better.
It is also not a consumption model. Data vault is an integration and history layer; business-facing marts are built on top of it, so adopting it means maintaining two models rather than one.
The costs to state plainly
- Many more tables than an equivalent dimensional model.
- Query complexity, with many joins for straightforward questions.
- Requires disciplined implementation. Partially-applied data vault has the complexity without the properties.
- Specialist knowledge, which is scarcer than dimensional modelling expertise.
The judgement
Data vault buys resilience to source change and auditable history, and pays in complexity and joins. For a large enterprise integrating many systems under audit obligation, that is a good trade. For a product company with a handful of sources, it is over-engineering that will be resented — and the complexity will be worked around rather than maintained.