How to design a "Data Vault 2.0" model for highly volatile source systems?

All answers to this question.

Data Vault 2.0 is specifically designed for the problem you’re describing. By separating the business keys (Hubs) from the descriptive context (Satellites) and the relationships (Links), you can add new sources without refactoring your existing model. This is a life-saver for auditability since you never delete or update data; you just add new records with timestamps. However, fair warning: you MUST automate the ETL. If you try to hand-code a Data Vault, your team will drown in the sheer number of tables. Use a tool like dbt or Wherescape.

   Answered 2025-05-15 by Karen Adams

Since Data Vault results in many small tables, are you concerned about the join-heavy performance on your specific database engine, or are you running on a modern MPP like BigQuery?

   Answered 2025-06-10 by Thomas Baker

• Thomas, we are on Snowflake, so the MPP engine handles the joins quite well. Our biggest worry is actually the complexity for our BI analysts, so we are planning to build a "Virtual Star Schema" layer on top of the Vault to keep things user-friendly.

     Commented 2025-06-22 by Brian Nelson

The "Business Vault" layer is key. Don't let your users query the raw hubs and satellites directly. Create cleaned-up views that look like a traditional star schema for them.

   Answered 2025-07-12 by Dorothy Evans

• Exactly, Dorothy. The Vault is for the "plumbing" of the data warehouse, while the star schema remains the best "interface" for the business.

     Commented 2025-07-15 by Robert Young