Kimball or Data Vault: how I actually choose

Every client asks the same question at some point: should we model this in Kimball, or go with Data Vault? The honest answer is that the modelling approach is downstream of a different question — how many source systems feed this platform, and how often does their structure change?

Kimball earns its keep when there's a small, relatively stable set of sources and the business wants fast, intuitive reporting. A well-built star schema is easy for a BI tool to query and easy for a business analyst to reason about. I reach for it on engagements where the reporting layer is the product — one clear set of facts and dimensions, built to answer known business questions.

Data Vault starts to win once you're integrating five, ten, or twenty source systems that all shift independently — new ERP modules, new SaaS tools, acquisitions. Its hub-link-satellite structure isolates change: a source system rewiring its schema means adding satellites, not remodelling the world. The trade-off is that a Data Vault model is not meant to be queried directly by a business user — you still build a Kimball-style layer on top of it for reporting.

In practice, the platforms I build most often end up as both: Data Vault as the integration layer that absorbs source-system churn, with a dimensional layer on top that the business actually queries. The question isn't which one is correct — it's which layer of the platform you're modelling, and how much source-system volatility that layer needs to absorb.