Definition
A data vault is a way of modeling data in a warehouse that splits information into three kinds of tables: hubs, which hold the unique business keys for core concepts like customer or product; links, which record relationships between those concepts, like a customer placing an order; and satellites, which hold the descriptive attributes and their history, attached to a hub or a link. Instead of one table per business concept the way a star schema builds a dimension, a data vault spreads that same concept across a hub for identity, and one or more satellites for its changing attributes over time.
The reason data vault modeling exists is that business rules, source systems, and reporting needs all change over time, and traditional warehouse models tend to require significant rework whenever a source system changes shape or a new one gets added. Data vault was designed specifically to absorb that kind of change without redesigning the whole model, by keeping the raw identity and relationship structure separate from the descriptive detail that tends to shift as source systems evolve. It also puts a strong emphasis on keeping a full history of every change, since satellites are typically insert-only and never overwritten.
What distinguishes a genuine data vault from just splitting tables into smaller pieces is the discipline around business keys and the insert-only philosophy. Hubs are built around the actual business identifiers an organization uses, not surrogate database keys invented for convenience, which is what lets data from different source systems be integrated around a shared understanding of what a customer or a product actually is. And because satellites never update or delete existing rows, only add new ones as attributes change, the full history of every change is preserved by construction rather than by a separate auditing process bolted on afterward.
By 2026, data vault modeling is used mainly in larger organizations, especially regulated industries like finance and insurance, where auditability, full historical traceability, and the ability to onboard new source systems without a full redesign are worth the added modeling complexity. It has not become mainstream the way star schemas have, partly because it demands more upfront discipline and produces a warehouse structure that is harder for an average analyst to query directly, which is why most data vault implementations add a simpler reporting layer, often shaped like a star schema, on top.
This page covers how hubs, links, and satellites fit together, how data vault compares to a star schema, what separates it from a plain normalized model, and where its extra complexity is worth paying for. The idea worth keeping is that a data vault trades query simplicity for adaptability and historical completeness, and that tradeoff only makes sense when an organization actually needs to keep integrating new sources and preserving full history over a long time horizon.
Key Takeaways
- A data vault splits data into hubs for identity, links for relationships, and satellites for descriptive attributes and history.
- It exists to absorb changing source systems and business rules over time without requiring a full warehouse redesign each time.
- It is defined by business-key-driven hubs and insert-only satellites, which preserve full history by construction.
- By 2026 it is used mainly by larger, often regulated organizations that need auditability and long-term adaptability more than query simplicity.
- It trades ease of querying for adaptability and historical completeness, which is only worth it for organizations that actually need both.
How a Data Vault Works
A hub table holds the unique business keys for one core concept, like customer, product, or order, along with a generated surrogate key used internally and metadata about when and from where that key was first loaded. Critically, a hub holds only the identity of the concept, nothing descriptive. A customer hub has a customer business key, a surrogate key, and load metadata, but no name, no address, and no other attribute that could change over time.
A link table records a relationship between two or more hubs, such as a customer placing an order, or an order containing a product. It typically holds the surrogate keys of the hubs it connects, plus its own surrogate key and load metadata, and like hubs, it stays focused purely on the fact that a relationship exists, not on describing that relationship's details. If the relationship itself has descriptive attributes, like an order date or a discount applied, those live in a satellite attached to the link.
A satellite table holds the actual descriptive attributes for a hub or a link, along with a timestamp marking when that version of the data became true. A customer satellite might have name, address, and segment, with a new row added every time any of those attributes change, rather than the existing row being updated. This is what makes satellites insert-only in practice: history accumulates as new rows rather than disappearing through overwrites.
Loading a data vault typically follows a consistent pattern regardless of which source system data comes from: identify or create the relevant hub records, identify or create the relevant link records, and insert a new satellite row if any tracked attribute has changed since the last load. Because this pattern is the same for every hub, link, and satellite, loading logic tends to be highly repeatable and automatable, which is a big part of the appeal for teams integrating many source systems.
A Data Vault Compared to a Star Schema
A star schema organizes a warehouse around one flat fact table and a handful of flat dimension tables, optimized so that most business questions can be answered with a small, predictable number of joins. A data vault spreads the same information across many more tables, hubs, links, and satellites, none of which are typically queried directly by an analyst, because the structure is optimized for loading, integration, and history, not for being read easily by a human writing SQL by hand.
This means a star schema is generally far friendlier for direct reporting and BI tool usage, since its shape maps closely to how people naturally think about a business question, sales by region by month. A data vault requires reconstructing that same shape by joining across several hubs, links, and satellites, which is not something most analysts want to do repeatedly, so data vault warehouses almost always add a star-schema-like reporting layer built on top of the vault rather than expecting people to query the vault directly.
Where a data vault pulls ahead is adaptability and history. Adding a new source system to a star schema often means altering dimension tables or rethinking the fact table's grain, which can ripple into every report built on top of it. Adding a new source to a data vault typically means adding new hubs, links, or satellites without touching the existing ones, since the model is built specifically to extend without disrupting what already exists. And because satellites are insert-only, a data vault retains a full history of every attribute change automatically, where a star schema needs deliberate, separate design work to track history at all.
In practice, many large organizations end up using both: a data vault as the durable, adaptable core that absorbs new sources and preserves history, with a star schema layer generated from it for the actual reporting and analysis that people do day to day. Treating the two as alternatives rather than complementary layers misses how they are actually used together in real warehouses.
What Makes a Data Vault Different From a Plain Normalized Model
A plain normalized model, like the kind used to design a transactional database, splits data into narrow tables to avoid redundancy, but it does not have a fixed, repeatable pattern for how every business concept and relationship should be structured. Two normalized schemas designed by different people for similar data can look quite different, because normalization is a general principle applied case by case, not a specific, standardized set of table roles.
Data vault modeling imposes a strict, repeatable pattern: every business concept becomes a hub, every relationship becomes a link, every set of descriptive attributes becomes a satellite, always following the same rules about business keys, surrogate keys, and insert-only history. This rigidity is deliberate, and it is what makes data vault loading so automatable, since the same loading logic applies regardless of which specific hub, link, or satellite is being populated.
Normalized transactional models are also generally designed to be updated in place, since an application needs to reflect the current state of the world accurately and efficiently. Data vault satellites are explicitly designed around preserving every past state as well as the current one, which a plain normalized transactional model typically does not attempt to do without extra, separate history-tracking mechanisms layered on.
So while both approaches avoid the kind of denormalization a star schema embraces, they solve different problems. Normalization in a transactional system is about efficient, correct, current-state storage for an application. Data vault modeling is about building a warehouse core that can absorb new sources, preserve full history, and be loaded in a highly consistent, automatable way, and it happens to use a normalized-style structure as the means to that end rather than as the goal itself.
Where a Data Vault Fits and Where It Does Not
A data vault fits well for large organizations that integrate many source systems over a long period, where new sources are expected to be added regularly and the warehouse needs to absorb them without repeated redesign. It also fits well in regulated industries like finance, insurance, and healthcare, where being able to show exactly what the data looked like at any past point in time, and where each piece of data came from, is a genuine requirement rather than a nice-to-have.
It also fits well when multiple teams or systems need to load data into the same warehouse independently and in parallel, since the consistent hub-link-satellite pattern and the insert-only nature of satellites make concurrent loading from different sources more manageable than it would be against a tightly coupled star schema. Teams can build and load their own hubs and satellites without waiting on a central modeling team to redesign a shared dimension table first.
A data vault fits poorly for smaller organizations or simpler warehouses with a small, stable number of source systems, where the adaptability a data vault buys is never actually exercised and the extra modeling complexity just becomes overhead with no real payoff. It also fits poorly as the direct interface for business analysts and reporting tools, since its structure is not built for ad hoc human querying the way a star schema is.
It is also a poor standalone choice for organizations that need fast time to value on a new warehouse project, since building out a data vault properly, with its hubs, links, satellites, and loading automation, plus a reporting layer on top, takes considerably more upfront design and engineering effort than building a star schema directly against a handful of known source systems.
How to Use Data Vault Modeling Well
Get the business keys right before building anything else, since hubs are built around them and a wrong or inconsistent choice of business key propagates through every link and satellite attached to that hub. Spend real time understanding how a source system actually identifies a customer or a product, including messy realities like the same customer having different identifiers across systems, before locking in a hub's business key definition.
Keep hubs and links strictly free of descriptive attributes, resisting the temptation to add a convenient extra column to a hub just because it seems harmless. The discipline of keeping identity and relationships completely separate from descriptive detail is what makes the model resilient to change, and even small violations of that discipline tend to reintroduce the same brittleness data vault modeling was meant to avoid.
Build the satellite structure around how attributes actually change together, grouping attributes that tend to change at the same time and rate into the same satellite, rather than either dumping everything into one giant satellite or splitting every single attribute into its own. Getting this grouping wrong does not break the model, but it does make loading and querying more awkward than it needs to be.
Plan for a reporting layer from the start rather than treating it as an afterthought, since almost nobody wants to query hubs, links, and satellites directly for day to day reporting. Deciding early how a star-schema-like layer will be generated from the vault, and keeping that generation process automated and repeatable, saves a lot of pain compared to bolting it on after the vault is already in production.
Automate the loading process as much as possible, since the whole appeal of the consistent hub-link-satellite pattern is that loading logic can be templated and reused across every source system rather than hand-written per table. Organizations that build a data vault but hand-code every load defeat much of the point, and end up with most of the complexity of data vault modeling without most of its efficiency benefit.
Best Practices
- Nail down business key definitions carefully before building hubs, since inconsistencies propagate through every link and satellite.
- Keep hubs and links free of descriptive attributes, preserving the strict separation that makes the model resilient to change.
- Group satellite attributes by how often and together they actually change, rather than one giant satellite or one per attribute.
- Design a star-schema-like reporting layer on top of the vault from the start, since few people should query the vault directly.
- Automate loading logic across hubs, links, and satellites, since a consistent, templated load process is most of the model's real payoff.
Common Misconceptions
- A data vault is not a specific software product; it is a modeling methodology that can be implemented on almost any database.
- A data vault is not meant to be queried directly by business analysts; a separate reporting layer is normally built on top of it.
- A data vault does not eliminate the need for a star schema; most implementations still generate one for actual reporting use.
- A data vault is not just extra normalization; its defining traits are business-key-driven hubs and insert-only, history-preserving satellites.
- A data vault is not automatically worth building; its adaptability and history benefits mainly pay off for organizations integrating many changing sources.
