Why the architecture decision matters
Data teams are being asked to do more with every passing year. They must bring together a growing number of sources, answer business questions that cut across departments, keep a reliable record of what happened in the past and, increasingly, prepare data that analytics and AI initiatives can actually use. The architecture behind the data warehouse is what determines whether those demands can be met calmly or only through constant rework.
That is why the choice between a traditional data warehouse and Data Vault is not merely a technical preference. It shapes how an organisation absorbs change, how easily it can trace a figure back to its source, how governance is applied and how much effort maintenance will require in three or five years. It also determines which future use cases remain within reach and which will demand a new project.
The central question can be put simply: should you build a traditional data warehouse around today's reporting needs, or create a more flexible data foundation designed to evolve? The answer depends on your context, and the rest of this article sets out how to reason about it.
What is a traditional data warehouse?
A traditional data warehouse is designed to make analytical reporting reliable and fast. Data is extracted from operational systems, cleaned and reshaped into a structure built for analysis, most often a dimensional model of facts and dimensions. Facts record measurable events such as sales or invoices, while dimensions describe the context around them: customer, product, period, region.
This approach has real strengths. It works particularly well when business requirements are well defined, because the model can be designed precisely around the questions the business wants to answer. Curated facts and dimensions give BI users a clear and understandable consumption layer, and queries that are known in advance can be optimised for performance. For many organisations, this is exactly what reporting needs.
When the source landscape and the analytical needs are relatively stable, a traditional warehouse can serve the business well for years. The difficulty appears when that stability disappears. Each new source has to be fitted into a model designed for the previous situation, and a change in a business definition can ripple through tables, transformations and reports at once.
History is another sensitive point. Many warehouses keep the current state of data, or only the history that was anticipated when the model was designed, which makes it hard to reconstruct what a customer record or a contract looked like at a given date. When several departments need different views of the same data, the model tends to accumulate exceptions. Over time, the warehouse can become difficult to understand, slow to change and expensive to maintain.
What is Data Vault?
Data Vault 2.0 is a modelling and architecture approach built for integration, history and change. Rather than shaping data immediately around a specific report, it first organises data around the business itself, and keeps business-facing structures for a later layer. Its logic rests on three types of objects.
Hubs represent the core business concepts of the organisation, identified by their business keys: a customer number, a product code, a contract reference. Links record the relationships between those concepts, such as the link between a customer and an order. Satellites hold the descriptive and contextual information about hubs and links, and they keep it historised, so that every change is stored rather than overwritten.
This separation is what gives Data Vault its resilience. Because business concepts, relationships and descriptive context are stored independently, a new source can usually be added by attaching new satellites or links rather than redesigning existing structures. A change in a source system affects only the part of the model that describes it. And because satellites keep every version of the data, the history needed for audit and analysis is preserved by design.
For a decision-maker, the key idea is not the technical detail of each object. It is that Data Vault separates the stable part of the organisation, its business concepts and their relationships, from the parts that change constantly: sources, attributes and definitions.
Traditional data warehouse and Data Vault: what is the real difference?
The two approaches are often presented as rivals, but they do not necessarily compete at the same layer. A Data Vault forms the integration and history layer of the architecture. On top of it, organisations still publish business-facing Information Marts, which can take the form of facts and dimensions, feed dashboards or serve other analytical outputs. In other words, the dimensional model does not disappear; it is derived from a more stable foundation.
The following table summarises how the two approaches typically differ, and what each difference means in practice.
| Criterion | Traditional data warehouse | Data Vault approach | Practical implication |
|---|---|---|---|
| Starting point | Known reporting requirements | Business concepts and keys | Data Vault is less tied to the first reports |
| Modelling logic | Facts and dimensions | Hubs, links and satellites | Integration and presentation are separated |
| Historization | Depends on design choices | Built into satellites | Past states can be reconstructed |
| Source integration | Sources fitted into a target model | Sources attached to business concepts | Multiple sources coexist more easily |
| Handling of change | Often requires redesign | Mostly additive | Less rework when sources or rules change |
| Adding new sources | Can affect existing structures | New links or satellites | Extension without rebuilding |
| Documentation and lineage | Often maintained separately | Follows the model's structure | Easier to trace a figure to its source |
| Data quality | Usually applied in transformations | Can be applied between raw and business layers | Raw data stays available for checks |
| Maintenance | Grows with exceptions | Repetitive patterns, suited to automation | Automation becomes essential |
| Multiple future use cases | Designed for defined uses | Shared, reusable foundation | New uses rely on the same base |
| BI and Information Marts | Directly the reporting layer | Marts published from the vault | BI keeps a familiar structure |
| AI readiness | Limited to modelled data | Historised, traceable foundation | Better starting point for AI |
Read as a whole, the table shows that the difference is less about reporting than about what lies underneath it. A traditional warehouse optimises the path from known sources to known questions. Data Vault optimises the ability to keep integrating, keep history and keep changing without starting again, while still delivering the dimensional structures that BI users expect.
It also highlights a trade-off. Data Vault introduces more objects and more repetitive patterns than a single dimensional model. That is precisely why the way it is implemented matters as much as the method itself, a point we return to below.
When is a Data Vault approach particularly relevant?
Data Vault is not the right answer to every situation. It becomes especially relevant when several of the following conditions apply to your organisation.
When sources are numerous or changing
Few organisations rely on a single system. Data usually comes from an ERP, a CRM, finance tools, operational applications, spreadsheets and sometimes external providers. Each of these systems identifies customers or products in its own way and evolves on its own schedule. Data Vault lets these sources coexist around shared business concepts, so that integrating a new system or replacing an old one does not force a redesign of everything built so far.
When history matters
Current-state data answers the question of where things stand today. Many important questions, however, are about the past: what did this contract look like when it was signed, how did a customer's situation evolve, which figures were known at the time of a decision? Audit, performance analysis and regulatory reporting all depend on reliable history. Because Data Vault stores changes rather than overwriting them, that history is preserved from the start rather than reconstructed afterwards.
When business definitions evolve
What counts as an active customer, a product family or a key performance indicator is rarely fixed forever. Reorganisations, new offers and new regulations regularly change these definitions. In a traditional warehouse, such changes can spread across the model and its transformations. With Data Vault, raw data and its history remain intact in the foundation, and new definitions can be applied in the business layer and Information Marts without losing the ability to compare with the past.
When several use cases must share the same foundation
Reporting is often only the first use of data. Operational applications, data products, advanced analytics and AI initiatives soon follow, each with its own expectations. Building a separate pipeline for every new need multiplies costs and inconsistencies. A governed Data Vault foundation allows these uses to rely on the same integrated, historised data, so that each new initiative starts from a trusted base rather than from scratch.
When traceability and auditability are essential
When a figure is questioned in a steering committee or by an auditor, the organisation needs to know where it came from, when it was loaded and which transformations were applied along the way. Data Vault keeps the link between data and its source, along with loading information, which makes this kind of explanation possible. For regulated sectors in particular, traceability is not a nice-to-have but a requirement.
Why automation matters
Data Vault is powerful, but its strength comes with a cost when it is implemented by hand. The same patterns repeat for every hub, link and satellite: loading logic, historisation, key handling, technical columns. Writing and maintaining this code manually is time-consuming and error-prone, and the effort grows with every new source. Without automation, the flexibility promised by the method can be lost in the workload required to deliver it.
Automation changes this equation. When code is generated from the model, the repetitive work is handled consistently and teams can focus on business modelling. The same logic applies to the integration of sources, to quality checks that should run with every load, to the orchestration of workflows, to documentation that should stay aligned with what is actually deployed, and to the delivery of Information Marts to business users.
This is where the value of beVault lies. The methodology itself is public and well documented; what makes the difference in practice is the ability to industrialise the full path from business model to usable data, and to keep that path maintainable as the organisation evolves.
What beVault adds to a Data Vault approach
beVault is a platform designed to move organisations from architectural principles to an operational data foundation. Rather than adding one more tool to assemble, it brings the main steps of a Data Vault project together in one environment.
It starts with modelling business concepts. Teams describe their business entities and relationships in a model that both business and technical people can read, and that model becomes the reference from which the rest is built. Connecting source systems then consists of mapping each source to those concepts, which keeps integration aligned with the business view rather than with the structure of each application.
Once data is loaded, beVault preserves history following Data Vault principles, so past states remain available for analysis and audit. Data quality checks can be defined and run as part of the data flows, allowing issues to be detected and followed up before they reach reports. Workflows are orchestrated within the platform, so that loading, controls and publication run in a coherent sequence.
Documentation and lineage are part of the same picture. Because transformations derive from the model and the mappings, it becomes easier to document what has been built and to follow the path of data from its source to its use. Finally, beVault helps publish Information Marts that present data in a form suited to BI and reporting, while the underlying foundation remains historised and governed. That same foundation is a sound starting point for future AI use cases, which need data that is reliable, traceable and understood.
How to choose between the two approaches
There is no universal answer, but there are clear signals. A traditional data warehouse may be the more suitable choice when the source landscape is limited, requirements are stable and the analytical model is well understood. If the number of future use cases is limited and the organisation has a clear, narrow scope, a well-designed dimensional model can deliver value quickly without the additional structure of a Data Vault.
A Data Vault approach becomes more suitable when sources and business requirements are expected to evolve, when reconstructing historical states matters, or when several business domains need to be integrated. It also makes sense when traceability and governance are important, when the organisation wants a reusable foundation rather than a series of point solutions, and when BI, analytics and AI use cases are expected to grow over time.
In practice, the decisive question is often not where you are today but where you expect to be in a few years. An architecture that fits current reports perfectly can become a constraint once the business changes direction. Conversely, a foundation designed for change may feel heavier at the start, which is why automation and a progressive approach are so important.
A practical adoption path
Choosing Data Vault does not mean transforming the entire architecture at once. The most successful projects start with a limited, valuable scope and extend from there. A typical path looks like this:
- Identify the most valuable business domain to start with.
- Map the relevant sources for that domain.
- Define the shared business concepts and their keys.
- Establish quality and governance rules.
- Build the first part of the foundation.
- Publish a first Information Mart.
- Validate the result with business users.
- Extend the model and add new sources progressively.
This progression delivers visible results early, while laying a foundation that each subsequent step can reuse. It also allows an existing data warehouse to keep running during the transition: the new foundation can take over domain by domain, rather than through a single high-risk migration.
Conclusion
The choice between a traditional data warehouse and Data Vault is not a choice between old and new technology. Both have their place, and a Data Vault foundation usually still feeds the dimensional structures that BI users know well. The more useful question is whether your architecture can:
- absorb change without constant rework;
- preserve history reliably;
- support trusted reporting;
- remain understandable over time;
- serve several future use cases;
- give teams enough autonomy to evolve the platform.
If the answer to several of these questions is uncertain, a Data Vault foundation deserves serious consideration. beVault offers a way to industrialise that foundation and make it operational, for organisations that need data that is reliable, governed and reusable.
Frequently asked questions
Is Data Vault a replacement for a traditional data warehouse?
Not exactly. Data Vault typically serves as the integration and history layer of a data warehouse. Business-facing structures such as facts, dimensions and Information Marts are still built on top of it, so reporting keeps a familiar form.
Is Data Vault suitable for small or mid-sized organisations?
It can be, particularly when they combine several sources or expect their needs to grow. Automation and a progressive start on a limited scope help keep the effort proportionate to the organisation's size.
Does Data Vault support BI and reporting?
Yes. BI tools usually consume Information Marts published from the Data Vault rather than the vault itself. These marts present data in a structure suited to analysis while relying on a historised and traceable foundation.
Why is historisation important?
Because many questions concern the past: how a situation evolved, what was known at a given date, or how to recalculate a former report with the same rules. Historisation also supports audit and regulatory requirements.
Can Data Vault work with an existing data warehouse?
Yes. A Data Vault foundation can be introduced progressively, domain by domain, while the existing warehouse continues to serve current reports. This limits risk and avoids a single large migration.
What does beVault automate?
beVault automates the path from business model to usable data: code generation from the model, source integration, historisation, data quality checks, workflow orchestration, documentation and the publication of Information Marts.
Further reading
Next step
Are you assessing the next step for your data warehouse?
Discover how beVault can help you build a historised, governed and evolving data foundation.