What is Data Vault?

Data Vault is a data modeling methodology created by Dan Linstedt, often presented as a third way beyond the two classic data warehousing schools, Kimball's dimensional schema and Inmon's normalized model. It splits data into three table types: hubs, representing business entities (a customer, a product, a supplier) identified by a key stable over time; links, recording relationships between entities (this customer bought this product at this store); and satellites, holding the descriptive attributes of hubs and links, with full historical tracking of every change. The structure is deliberately rigid in shape and flexible in content: adding an attribute or a new source means adding a satellite, not modifying existing tables. This makes it particularly well suited to enterprise data warehouses with many constantly changing sources, where every new integration would otherwise risk requiring a revision of the schema already in production, with knock-on effects on every pipeline and report that depends on those tables.

Why it was created

Data Vault was built for enterprise data warehouses that need to ingest data from many different, constantly changing sources: new operational systems, company acquisitions, integrations with external partners. In that context, adding a source should not require redesigning the existing schema, a real risk in a mature dimensional model with dozens of shared dimensions. The hub, link and satellite structure is designed precisely to be extended without destructive changes: new sources add their own hubs, links and satellites, without touching the ones already in production.

The trade-off and when it makes sense

The price of that flexibility is a model with far more tables and joins than a simple star schema: querying a Data Vault directly is complex and poorly suited to dashboard building. For this reason, in practice, a dimensional layer is almost always built on top of the Data Vault for the end user: the vault serves as a permanent, historized integration layer, append-only and therefore auditable, distinct both from the transient staging area feeding it and from the dimensional consumption layer sitting on top of it. It makes sense for organizations with many heterogeneous data sources, needs for full audit and historical traceability, or regulated industries that must prove the provenance of every piece of data. For a single, stable data mart with few sources that rarely change, it is almost always overengineering.

Why it matters for your business

Data Vault is not a replacement for the Kimball versus Inmon debate, it is often a complementary layer upstream of the dimensional data warehouse: it integrates and historicizes raw data from many sources, while the star schema remains the layer that makes it readable and fast to query for the business. Knowing this distinction helps choose the right architecture instead of forcing a single model to do two different jobs.