"Should we use Data Vault or Kimball?" is one of the most common questions in data warehouse design, and it is usually framed as a choice between rivals. It is better understood as a question about layers. Kimball dimensional modeling is a way to design data for consumption: star schemas that analysts, BI tools and semantic layers query directly. Data Vault 2.0 is a way to design data for integration: a historised, auditable layer that absorbs many sources and changes in them. Many mature warehouses use both, with a vault underneath and stars on top.
This article compares the two on the dimensions that actually drive the decision, then shows what a hybrid looks like in practice.
The two approaches in one paragraph each
Kimball organises the warehouse around business processes. Each process becomes a fact table at a declared grain, surrounded by denormalised dimension tables. Dimensions are conformed across facts, planned with a bus matrix, so that separate processes can be analysed together. History in dimensions is handled with slowly changing dimension techniques. The model is optimised for query simplicity and business understanding.
Data Vault 2.0 organises the warehouse around business keys. Each core business concept becomes a hub, relationships become links, and descriptive attributes from each source become satellites with full history. Everything is insert-only and loaded with standard, parallelisable patterns. The raw vault stores source data as delivered; business rules are applied later in a business vault, and consumption happens in information marts built on top. The model is optimised for integration, auditability and change.
For the mechanics of each, see Data Vault hubs, links and satellites and fact vs dimension tables.
Side-by-side
| Kimball dimensional | Data Vault 2.0 | |
|---|---|---|
| Primary purpose | Analysis and reporting | Integration and history |
| Organising principle | Business processes and their measurements | Business keys and their relationships |
| Core structures | Facts, dimensions | Hubs, links, satellites |
| Who queries it | Analysts, BI tools, semantic layers, AI agents | Data engineers; end users query marts built on it |
| Number of tables | Fewer, wider | Many more, narrower |
| Joins per query | Few | Many (usually hidden behind marts) |
| History | SCD per dimension attribute, chosen upfront | Full history of every source attribute by default |
| Business rules | Applied during load into facts and dimensions | Kept out of the raw vault; applied in business vault or marts |
| Adding a new source | Often requires changes to existing dimensions and loads | Add new satellites and possibly hubs and links; existing tables untouched |
| Auditability | Depends on design; transformed data | Strong; raw vault can reproduce what each source said, when |
| Load patterns | Custom per table (SCD merges, fact lookups) | Three standard patterns (hub, link, satellite), highly automatable |
| Time to first report | Shorter | Longer, because marts are still needed |
The questions that decide it
How many source systems feed the same business concepts?
If customers come from one CRM and orders from one shop platform, conformance is straightforward and the integration problem is small. A dimensional model built directly from staged source data works well.
If customers come from six systems (two CRMs after an acquisition, a billing system, a support desk, a loyalty app and a data provider), each with its own identifiers and partial attributes, the integration problem dominates. A vault gives you a place to register every key from every source, record how they match, and keep each source's view intact while you decide how to build a golden record.
How often do sources and requirements change?
In a dimensional model, adding a new source of customer attributes usually means changing dim_customer's load, maybe its structure, and testing every fact that references it. In a vault, the new source gets its own satellite on hub_customer. Nothing existing is modified. If your organisation acquires companies, replaces systems or onboards new data providers regularly, that isolation is worth a lot.
What are the audit and regulatory requirements?
Banking, insurance, healthcare and public sector organisations often need to show exactly what a source system said at a point in time, and how a reported number was derived. A raw vault that stores insert-only, source-specific history with load timestamps and record sources makes that straightforward. A dimensional model can be designed for it, but it is not the default.
Who needs value, and how soon?
A dimensional model goes straight from staging to something analysts can use. A vault adds a layer, and its raw tables are not directly useful for reporting. If you are a small team that needs a reliable sales dashboard next month, building a vault first is usually the wrong order.
How much automation do you have?
A vault has many more tables than a star covering the same scope. Writing every hub, link and satellite and their loads by hand is slow and error-prone. Data Vault is practical at scale when DDL and load code are generated from metadata, whether through dbt packages, a modeling tool or in-house templates. Without automation, the cost often outweighs the benefit.
Rules of thumb
Pick Kimball directly on staged sources when:
- You have a handful of well-understood source systems.
- The main goal is analytics and reporting.
- The team is small and needs to deliver incrementally.
- Audit requirements are met by keeping raw source extracts.
Pick Data Vault as an integration layer when:
- Many sources describe the same entities with different keys.
- Sources change often, or the business grows by acquisition.
- Full, source-level history and auditability are requirements.
- You can automate model and load generation.
In both cases, consumption should still be dimensional. A vault is not a reporting model.
Hybrid architectures
The most common real-world architecture is a layered one:
sources -> staging (typed, hashed, one view per source table) -> raw vault (hubs, links, satellites; insert-only, no business rules) -> business vault (PIT tables, bridges, computed satellites, business rules) -> information marts (Kimball star schemas: facts and conformed dimensions) -> semantic layer (metrics and dimensions for BI and AI)Each layer has a single job. The vault integrates and historises. The marts make it usable. The semantic layer defines the metrics consistently on top of the marts.
Building a dimension from the vault
With a point-in-time table for customers, a Type 2 dim_customer becomes a deterministic query over the vault rather than a stateful merge:
create or replace view mart.dim_customer asselect md5(concat_ws('||', p.hk_customer, cast(p.snapshot_dts as varchar))) as customer_key, h.customer_number as customer_id, crm.name as customer_name, crm.tier as tier, bill.billing_country as country_code, p.snapshot_dts as valid_from, coalesce( lead(p.snapshot_dts) over (partition by p.hk_customer order by p.snapshot_dts), timestamp '9999-12-31 00:00:00' ) as valid_tofrom business_vault.pit_customer pjoin raw_vault.hub_customer h on h.hk_customer = p.hk_customerleft join raw_vault.sat_customer_crm crm on crm.hk_customer = p.hk_customer and crm.load_dts = p.sat_customer_crm_ldtsleft join raw_vault.sat_customer_billing bill on bill.hk_customer = p.hk_customer and bill.load_dts = p.sat_customer_billing_ldts;This is one of the practical benefits of the hybrid: marts can be dropped and rebuilt from the vault at any time, so changing a dimension's SCD rules or adding an attribute is a rebuild, not a migration.
Facts from links and satellites
Facts come from links (the relationships between business keys) and their satellites (the measurements). An order line fact joins link_order_product and sat_order_line_shop for quantity and price, then looks up dimension keys for the order's customer and date.
Lighter-weight hybrids
Not every organisation needs a full vault. Common lighter patterns:
- Persistent staging plus Kimball. Keep an insert-only, historised copy of every source extract, then build stars from it. You get replayability and some auditability without hubs and links.
- Vault only for the hard domains. Use hubs, links and satellites for customer and product, where integration is painful, and build other areas dimensionally from staging.
- dbt snapshots as satellites. Snapshot source tables for history, which gives satellite-like behaviour, and model marts on top.
Common mistakes
Pointing BI tools at the raw vault. Business users facing dozens of hubs, links and satellites will build inconsistent joins and slow queries. Always provide marts.
Choosing a vault for a single-source warehouse. If there is only one system and few changes, the vault adds work without solving a problem you have.
Choosing Kimball and then patching integration into dimensions. When three sources feed dim_customer through a 400-line merge with precedence rules, the integration logic has nowhere clean to live. That is a sign a vault or at least a persistent staging layer would help.
Applying business rules in the raw vault. It removes the main benefit of the vault. Keep raw raw.
Treating it as a religious choice. Both are tools. The question is which problems you have.
Learn both in offdataai Learn
offdataai Learn has separate hands-on tracks for Dimensional Modeling (Kimball) and Data Vault 2.0. Each lesson has an exercise you build in the Model Builder, with an instant automated check, so you can try both approaches on the same business scenario and see the trade-offs for yourself. Both are included in the Explorer plan at $1/month.
For reference models, compare the dimensional modeling and Data Vault pages, or open the same industry in both styles from the templates.