Most database designers start with either a normalized relational model or a dimensional star schema, and for many applications, those approaches work perfectly well. But organizations managing large data warehouses fed by multiple source systems often hit a wall: the schema becomes brittle, historical data is hard to track, and onboarding a new data source means reworking tables that are already in production. Data Vault 2.0 was designed specifically to solve these problems. This article explains what it is, how it works, and how to use it in Navicat Data Modeler 4.
What Is Data Vault 2.0?
Data Vault 2.0 is a data modeling methodology developed by Dan Linstedt, originally introduced in the early 2000s and significantly expanded around 2013. Where the first version focused purely on modeling technique, version 2.0 broadened the scope to encompass architecture patterns, methodology, and integration with modern practices including agile development, cloud computing, and automation.
The core idea is straightforward: rather than combining identity, relationships, and descriptive attributes into a single table (as a traditional dimension table does), Data Vault 2.0 separates them into three distinct types of structure. This separation is what gives the methodology its resilience and flexibility.
The Three Building Blocks
Hubs represent core business concepts and store nothing but business keys, i.e. the natural identifiers that your organization actually uses, such as a customer ID, a product code, or an order number. Hence, a hub for customers would contain customer IDs and nothing else. Hubs are designed to be stable. As such, they don't change when source systems change, and they don't store anything that could become stale.
Links capture relationships between hubs. If a customer places an order, a link table records that relationship by holding the hash keys from the customer hub and the order hub. Links are also append-only and immutable, so once a relationship has been recorded, it stays. This makes links a reliable audit trail of every association that has ever existed between business entities.
Satellites are where descriptive attributes and history live. A satellite attached to a customer hub might store the customer's name, address, and contact details, together with timestamps that show when each version of those attributes was loaded. Because satellites are separate from hubs, you can have multiple satellites on a single hub - one per source system, or one per rate of change - without touching the hub itself. This is what makes Data Vault so adaptable when a new data source needs to be integrated.
When to Use It (and When Not To)
Data Vault 2.0 earns its complexity when you are building an enterprise data warehouse that needs to integrate many source systems, handle frequent schema changes, and maintain a full audit trail of how data has arrived and evolved over time. Regulated industries in particular - such as finance, healthcare, and insurance - benefit from the inherent auditability of the hub-link-satellite model, because every piece of data carries its load timestamp and source system as standard.
It is less well-suited to simpler analytical databases, small teams with limited modeling resources, or applications where query simplicity and performance on the integration layer matter more than flexibility. Data Vault is an integration layer, not a consumption layer. Hence, analysts should query a presentation layer (typically a star schema or data mart) built on top of it, not the vault itself. Teams that skip this distinction and query the vault directly often find the multi-table joins unwieldy.
Modeling Data Vault 2.0 with Navicat Data Modeler
Data Vault 2.0 support was introduced in Navicat Data Modeler 4, as both a stand-alone product and as part of Navicat 17.2 in March 2025. It is available alongside the tool's existing support for Relational and Dimensional modeling methodologies, meaning you can work with all three approaches within the same application.
When you select Data Vault 2.0 as your modeling method, the canvas and object types are tailored to the methodology. You work with the hub, link, and satellite constructs natively rather than approximating them using generic table objects, which matters both for clarity during the design phase and for generating accurate DDL when you are ready to deploy. The visual environment lets you see the hub-and-spoke structure of your model clearly, making it easier to reason about how entities connect and where new source systems should attach.
Navicat Data Modeler's broader feature set complements the Data Vault workflow well. Once a physical model is ready, the Synchronize to Database command compares the model against a live database and generates a deployment script for the differences, which fits naturally into the incremental, sprint-based development style that Data Vault 2.0 encourages. The Export Model to SQL/Script File feature generates the full DDL for the modeled schema, ready to be committed to version control or handed to a migration tool. And because Navicat Data Modeler supports a wide range of databases, including MySQL, PostgreSQL, SQL Server, Oracle, MariaDB, MongoDB, SQLite, and Snowflake, the same modeling workflow applies regardless of which engine sits underneath your data warehouse.
Conclusion
Data Vault 2.0 is not the right choice for every project, but for organizations building enterprise data warehouses that need to absorb change gracefully and maintain a reliable audit trail, it offers a level of resilience that traditional approaches struggle to match. The methodology has a learning curve, but the underlying principles - separate identity from relationships, separate relationships from description, and make everything auditable - are logical once the pattern clicks. With native Data Vault 2.0 support introduced in Navicat Data Modeler 4, teams now have a visual modeling environment that speaks the methodology's language directly, reducing the friction between design and implementation.
