Data Vault vs Data Warehouse: Modelling Compared

Is Data Vault different from a data warehouse?

Not in the way the question suggests. A data warehouse is a system that stores integrated data for analysis. Data Vault is a method for designing the tables inside that system. You do not choose one instead of the other. You choose how to model your warehouse, and Data Vault is one option.

The more useful comparison is Data Vault against dimensional modelling, the approach popularised by Ralph Kimball, which organises data into fact and dimension tables. Both can sit inside the same warehouse platform, on Azure, Snowflake or elsewhere.

If you want the basics first, see what is a data warehouse. For the wider design questions, data warehouse design covers the main decisions. NetMonkeys' data warehouse team works with both approaches, and recommends one only after looking at the sources.

What is Data Vault modelling?

Data Vault was developed by Dan Linstedt. It separates data into three kinds of table, each with a single job. The aim is to make the warehouse easy to extend and to keep a complete record of what was loaded and when.

• Hubs hold the unique business keys for core concepts, such as a customer number, a product code or an invoice number. A hub says that the thing exists.
• Links record relationships between hubs, such as a customer placing an order. They allow relationships to change without redesigning the model.
• Satellites hold the descriptive details and their history, such as a customer's address and the dates when it changed. Each satellite records when data was loaded and where it came from.

Because new attributes can be added as new satellites, and new relationships as new links, existing tables are rarely altered. That is the main attraction when sources change often.

The method also encourages a separation of duties. The raw vault records facts about what was received, without opinion. Business rules, which are more likely to change, live in a later layer. This keeps arguments about definitions away from the stored history, and it makes it easier to explain a number after the rules have changed.

What is dimensional modelling?

Dimensional modelling organises data around business events. A fact table records measurable events, such as sales, with numbers like quantity and value. Dimension tables describe the context, such as customer, product, date and location. This is often called a star schema.

It is designed for people. The table names match the way the business talks, and BI tools such as Power BI work naturally with it. Queries are simple, and performance for reporting is usually strong.

Its weakness is that it is shaped by the questions you knew about when you designed it, so it needs thought about future needs. Large changes in source systems or business rules can mean reworking tables. Our guide to The Data Warehouse Toolkit looks at the book that set out this approach.

How do Data Vault and dimensional modelling compare?

Neither approach is more correct. They solve different problems, and for that reason they are often combined.

How do auditability and change handling differ?

Auditability is where Data Vault is strongest. Every record carries a load date and a record source, and data is inserted rather than overwritten. You can reconstruct what the warehouse knew at a given time, and trace any value back to the system it came from. That is valuable in regulated sectors and where figures may be challenged.

Change handling follows from the same design. If a source system adds new fields, you add a satellite. If a new system holds the same customers, you load its keys into the existing hub. Existing reports are not disturbed.

Dimensional models can also keep history, using techniques such as slowly changing dimensions. They can be audited too, but the design must include the load logging and lineage deliberately. For many organisations that is enough.

When does Data Vault suit, and when does dimensional modelling suit?

Data Vault tends to suit organisations that match several of the following.

• Many source systems that change often. Mergers, new platforms and regular upgrades are typical triggers.
• Strict audit or regulatory requirements. You must show where data came from and how it changed.
• Several teams loading in parallel. The pattern-based design lets teams work on separate hubs and satellites.
• A long-lived enterprise warehouse. The extra structure pays back over years, not months.

Dimensional modelling tends to suit organisations that match these.

• A defined set of reporting needs. You know the main questions, and the sources are fairly stable.
• A small team. Fewer tables and well-known patterns keep the cost of building and handing over low.
• Business-led reporting. Analysts want to explore data directly in Power BI or Excel.
• A need for quick results. You want dashboards in weeks rather than a long foundation phase.

For many small and mid-sized businesses, a dimensional model is the better value. Data Vault is a considered choice for larger or more regulated environments, not a default.

What does Data Vault cost in complexity and skills?

Data Vault trades simplicity of querying for simplicity of loading and change. The costs are real and worth stating plainly.

• More tables and more joins. A single business concept may be spread across a hub, several satellites and links.
• An extra layer for reporting. You rarely point a BI tool at a raw vault. You build views or tables on top, which is more work.
• Specialist skills. Few BI developers know the method well. Training and strict standards are needed.
• Tooling and automation. The patterns are repetitive, so teams usually generate code with automation tools, which adds cost.
• Risk of overengineering. Adopting it for a small, stable source landscape adds structure that will never be used.

A sensible adviser will tell you when not to use it. If you have a few sources and clear reporting needs, a dimensional model is likely to deliver value sooner. A short review of your sources and reporting needs can confirm which side you are on.

How do the layers combine: raw vault, business vault and presentation layer?

In practice, Data Vault and dimensional modelling are often used together, so the choice is less binary than it appears. A common layered design looks like this.

1. Staging area. Source data lands as received, ready to be loaded.
2. Raw vault. Data is loaded into hubs, links and satellites with no business rules applied. This is the auditable record of what each source sent.
3. Business vault. Optional derived structures that apply shared business rules, such as calculated measures or cleansed values, still in vault form.
4. Presentation layer. Dimensional models, such as star schemas, are built from the vault for reporting. This is the layer users and BI tools see.
5. Semantic model and reports. Dashboards and reports sit on the presentation layer, with agreed measures defined once.

This gives you the traceability of Data Vault and the usability of a star schema. It also gives you more layers to build, test and support. The approach works best when there is a team to run it, and it is a design to grow into rather than a starting point for every project.

What does this look like in practice? An illustrative example

Take a hypothetical group of companies that has grown by acquisition. It now has four finance systems and three customer databases, and a regulator may ask how reported figures were built. Sources are still being retired and replaced, so structures keep moving.

This is a good case for a vault. Each new source is loaded into the raw vault using the same patterns, and customer keys from every system are matched in a hub. When one finance system is replaced, the new one is added as another source rather than forcing a redesign. The data migration and system integration work still has to be done, but the warehouse model absorbs the change.

Now take a hypothetical single company with an accounting package and a CRM, which wants a weekly sales and margin dashboard. A vault would add layers it does not need. A star schema with a calendar, customer, product and sales fact table would do the job sooner and cost less to maintain.

Both scenarios are invented, only to show the contrast. Real projects are rarely so clear cut, which is why the checklist below is worth working through with the people who will run the platform.

Does the platform change the choice?

Only a little. Both methods can run on Azure, Fabric, Snowflake and other modern platforms, and cloud storage costs have reduced the penalty of keeping many tables. The decision still rests on your sources, your audit needs and your team's skills.

Tool features change often, and vendors describe support for modelling patterns in different ways, so check each vendor's current documentation. Our overview of data warehouse platforms and the notes on Azure cloud services are useful for context.

Whatever you choose, document it. A model that only one person understands is a risk, however elegant it is. Write down the naming standards, the load rules and the reasons for each major decision, so the next engineer can pick it up without guesswork.

How do you decide? A short checklist

Answer these questions honestly. They matter more than the method's reputation.

1. How many sources do you have, and how often do they change? Many, with frequent change, favours Data Vault.
2. How strict are your audit and lineage needs? Regulatory pressure favours Data Vault.
3. How soon do you need dashboards? If it is soon, begin with a dimensional model.
4. Who will build and maintain it? Without Data Vault skills in the team, expect extra training or support.
5. Who will query the data? If business analysts query directly, you need a dimensional layer either way.
6. Can you start simple and add layers later? Often yes, provided you document and keep business keys consistent.

If you are unsure, NetMonkeys' data warehouse services team can review your sources and reporting needs and suggest a modelling approach. Business intelligence consultants can help with the reporting layer on top.