Data Vault 2.0 Made Simple — Part 1: Fundamentals Explained

Why Another Data Modeling Approach?

In today’s world, companies collect data from everywhere — applications, CRMs, IoT sensors, clickstreams, and third-party feeds. This data doesn’t arrive cleanly. It changes shape, sometimes has duplicates, and often evolves as business processes grow.

Traditional modeling techniques like Kimball (Star Schema) or Inmon (3NF Enterprise Data Warehouse) were created in an era of slower, structured data. They struggle with today’s fast-changing, high-volume, multi-source data — exactly the problem Data Vault 2.0 solves.

What is Data Vault 2.0?

Data Vault 2.0 (DV 2.0) is a methodology + modeling technique + architecture for building data warehouses that are:

• Scalable — grows as data sources grow.
• Flexible — can adapt to changes without redesigning everything.
• Auditable — keeps track of where data came from and when.
• Business-focused — always centers around business keys (like CustomerID, ProductID, AccountNo).

It was developed by Dan Linstedt and is considered the de facto modern standard for cloud data warehouses (Snowflake, Databricks, Azure, GCP, AWS).

The Core Building Blocks

Data Vault 2.0 breaks the data model into three main components. Think of them like Lego blocks that you can assemble and expand as needed. To make it clearer, let’s use a banking example:

1. Hubs (The Core Business Entities)

• Hubs store the unique identifiers of business concepts — not the relationships, just the anchor keys.
• In a bank, examples include Customer Hub (CustomerID), Account Hub (AccountNumber), and Branch Hub (BranchCode).
• Each hub only holds the key, a load date, and the record source. No descriptive details like names or balances.

A hub is like the anchor point: it says this customer exists, this account exists, this branch exists.

2. Links (Relationships Between Entities)

• Links record the connections between hubs.
• Example: A Customer–Account Link shows which customer owns which account. Another Account–Branch Link shows which branch manages which account.
• Links only store the relationship between keys, plus metadata (load date, record source).

Links are the bridges: they explain how hubs are related, but not the descriptive details.

3. Satellites (Context and History)

• Satellites attach to hubs or links to provide descriptive information and track changes over time.
• Example: A Customer Satellite stores name, address, phone, email with valid-from and valid-to dates. An Account Satellite stores account type, balance, and product info. A Customer–Account Link Satellite could track relationship type (primary holder, joint holder).
• Satellites ensure history is never lost — you can always see what changed, when, and from which source.

Satellites are the storytellers: they capture the “who, what, where, when” around hubs and links.

Putting It Together: A Simple Example

Imagine a banking system:

• Hub_Customer → Stores unique CustomerIDs.
• Hub_Account → Stores unique AccountNumbers.
• Hub_Branch → Stores unique BranchCodes.
• Link_Customer_Account → Connects CustomerID and AccountNumber (a customer owns an account).
• Link_Account_Branch → Connects AccountNumber and BranchCode (an account is managed by a branch).
• Sat_Customer_Details → Stores name, address, contact details, and tracks updates over time.
• Sat_Account_Details → Stores account type, balance history, interest rates.
• Sat_Branch_Details → Stores branch location, manager, contact info.
• Sat_Customer_Account_Relationship → Tracks relationship type (primary holder, joint holder) and changes in that relationship.

This modular approach means if tomorrow the bank introduces a new product (like credit cards or loans), you don’t break the existing model — you just add a new hub for that product and appropriate links/satellites to plug it into the ecosystem.

Data Vault 2.0 Layers

A Data Vault 2.0 implementation is always structured in layers, each serving a clear purpose. This layered approach separates raw data capture from business interpretation and final reporting. Let’s look at them step by step, and use a banking scenario as an example where helpful.

1. Staging Layer (Landing Zone)

All incoming data first lands here, loaded as close to source format as possible. This could include CSV files, API extracts, database dumps, or streaming events. The goal is simple: capture everything without loss, before transformations. In a bank this might mean raw feeds from the core banking platform, credit card processors, or loan systems.

2. Raw Vault (Immutable System of Record)

This is the heart of Data Vault. Data is loaded into hubs, links, and satellites exactly as received, with technical metadata (load date, source). No business rules are applied at this stage.

• Hubs anchor business keys (e.g., CustomerID, AccountNumber).
• Links connect those hubs (e.g., Customer–Account ownership).
• Satellites describe them with attributes and keep full history (e.g., balance, address, loan terms).

The Raw Vault ensures auditability and traceability. In regulated industries like banking or healthcare, this is critical: you can always show what data came from where, and when.

3. Business Vault (Applying Business Meaning)

The Business Vault extends the Raw Vault but does not introduce new core hubs, links, or satellites. Those remain part of the immutable Raw Vault. Instead, the Business Vault adds derived and business-oriented constructs that make it easier to work with data for analysis and reporting. Here, transformation rules, harmonization, and integration logic are applied consistently.

• Point-in-Time (PIT) tables make it easy to see an entity’s state at a given date (e.g., a customer’s balance as of month-end).
• Bridge tables simplify navigation of many-to-many links (e.g., joint accounts with multiple customers).
• Derived Satellites may be introduced to standardize or unify information across sources (e.g., consolidating different loan product codes into a common standard).

The Business Vault still adheres to DV 2.0 principles. It enriches and harmonizes the Raw Vault but never changes the original hubs, links, or satellites.

4. Information Marts (Consumption Layer)

The Information Marts are outside the vault. They are purpose-built models designed specifically for end-user reporting and analytics. These could be star schemas, wide denormalized tables, or semantic views.

• A bank might build a Customer 360 Mart combining customer, accounts, and product usage.
• A retailer could build a Sales Mart aggregating transactions, customers, and product details.
• A telecom operator might have a Network Performance Mart combining sensors, equipment, and incidents.

The key difference: Business Vault is still part of the back-end integration layer, enriching and aligning data while preserving lineage. Information Marts are consumer-facing, reshaped to answer business questions directly. Information Marts (Consumption Layer) The last layer reshapes the data into formats suited for analytics and reporting. This could be star schemas, wide denormalized tables, or semantic views.

• A bank might build a Customer 360 Mart combining customer, accounts, and product usage.
• A retailer could build a Sales Mart aggregating transactions, customers, and product details.
• A telecom operator might have a Network Performance Mart combining sensors, equipment, and incidents.

These marts are what BI tools, dashboards, and data science models consume.

Key Principle: The Raw Vault never changes. It is your immutable foundation. The Business Vault and Marts can be adapted as business needs evolve, but the Raw Vault always holds the original, auditable truth.

• Auditability → Every record is traceable back to source + timestamp.
• Agility → New products or regulations? Just add new hubs, links, and satellites without re-engineering the model.
• Parallelization → Teams can build and load different subject areas independently.
• Cloud Ready → Works seamlessly with Snowflake & Databricks, fitting modern scalability needs.

Common Misconception

“Isn’t Data Vault too complex with so many tables?”

This is a frequent concern, because when you compare a Data Vault model to a traditional star schema, the number of objects (hubs, links, satellites) is noticeably higher. However, the technical reality is:

• Yes, more tables: A single business concept like “Customer Account” might require a hub for Customer, a hub for Account, a link between them, and one or more satellites. This seems like overhead compared to a single fact table with dimensions.
• But less rework: That separation means when business rules, attributes, or relationships change, you only add or extend a satellite or a new link. You don’t rebuild entire fact tables or remodel existing structures.
• Change management is simpler: Because the Raw Vault is immutable, historic data remains intact. New business logic is layered in the Business Vault without disturbing what’s already there.
• Automation helps: Modern tooling — like ELT templates, dbt macros, Databricks notebooks, or Snowflake tasks — makes generating hubs, links, and satellites largely repeatable. Instead of manually building dozens of tables, you rely on patterns and automation.
• Performance is manageable: While joins can be more complex, techniques like Point-in-Time (PIT) tables and Bridge tables in the Business Vault optimize access. These are recommended practices in Data Vault 2.0.

In short: the apparent complexity is intentional. It provides scalability, auditability, and adaptability that outweigh the additional number of tables. With automation and best practices, organizations find the model both sustainable and future-proof.

Recap — The Big Idea

• Hubs = Business keys (Customer, Account, Product, Branch)
• Links = Relationships (Customer–Account, Account–Product, Account–Branch)
• Satellites = History + context (addresses, balances, product rules)
• Raw Vault = Store everything as-is
• Business Vault = Apply rules and prepare derived structures
• Information Marts = Serve analytics and reporting

What’s Next?

This was Part 1 — Fundamentals with a banking lens. In Part 2, I’ll show you how to implement a mini Data Vault 2.0 demo.

Takeaway: Data Vault 2.0 is like building a Lego city — you can start small and expand infinitely, while always knowing when and where each piece came from.

Conclusion

Data Vault 2.0 provides a balanced approach between the rigidity of traditional data warehouse models and the flexibility required in modern, fast-changing data landscapes. Its separation of concerns — hubs for keys, links for relationships, satellites for history — makes it possible to scale and adapt without losing track of lineage. While it may appear complex at first glance, automation and best practices make it practical and sustainable. For industries like banking, retail, healthcare, and telecom, Data Vault 2.0 offers the governance, agility, and scalability needed to future-proof their data platforms.