Data Vault vs dimensional: model for rate of change, not fashion

The Data Vault versus dimensional modeling argument is usually conducted as a loyalty test, and it should be conducted as a measurement. The deciding variables are boring and countable: how many source systems you integrate, how often they change shape, and what your audit obligations are. High rate of change across many sources argues for a vault; stable consumption semantics argue for a star; and in most serious platforms the honest answer is both, in sequence — vault in the integration layer, star projected on top for consumption.

The tell is hiding inside Data Vault's own toolbox. One of its standard satellite patterns is literally called split by rate of change: put rapidly changing attributes in one satellite and slow ones in another, so churn doesn't force rewrites of stable history. The methodology parametrizes itself on change rate — that's a signal about what problem it was built to absorb. Hubs pin business keys that almost never change; links record relationships; satellites soak up the descriptive churn, insert-only, timestamped, source-tagged. When a source system reorganizes, you add a satellite instead of refactoring a dimension. When an auditor asks what you knew and when, the load-date and record-source columns answer without archaeology. That insert-only, parallel-loadable discipline is also why the vault pattern lands so naturally on Delta tables — append-heavy writes with ACID merge are exactly what the format is optimized for.

Dimensional modeling optimizes for the opposite pressure: query comprehension. A star schema is a promise to the consumer — facts at a declared grain, conformed dimensions with agreed meanings, measures whose additivity is known. Slowly changing dimensions handle change, but as a managed exception; Kimball's machinery (Type-2 versioning, late-arriving members, conformed buses) works best when the business's descriptive vocabulary is reasonably settled. Stars are what BI tools, semantic layers, and increasingly LLM-facing metric views want to consume, because their semantics are legible.

So the architecture question is not "which is right" but "where does each rate of change live." Volatile, multi-source, audit-bearing integration belongs in a raw vault in the Silver layer — that's where change arrives. Consumption belongs in dimensional marts in Gold, projected from the vault: dimensions as views over hub-plus-satellite, facts loaded from links, point-in-time tables mitigating the vault's notorious join costs. The vault absorbs change so the star doesn't have to; the star provides meaning the vault never claimed to. The two models are a pipeline, not a rivalry.

The concession is about scale, and it's a real one: below a threshold of source count and churn, the vault is pure overhead. If you integrate three stable sources and your auditors are satisfied by table history, a straight Kimball star loaded from a clean Silver layer is simpler, cheaper, and easier to staff — hash-key hygiene, PIT tables, and vault loading patterns are a tax you should refuse until change rate forces the issue. Most mid-size platforms should start dimensional and adopt vault constructs only when source churn starts breaking dimensions faster than they can be refactored.

What I take into engagements: inventory the sources, measure schema-change frequency over the last year, write down the audit requirements — then pick the modeling posture the numbers demand. Fashion arguments about Linstedt versus Kimball are a way of avoiding that measurement. The rate of change is a property of your business; the model should be a function of it.