DATA ARCHITECTUREArchitecture

Inmon vs Kimball vs Data Vault

How data engineers design data that lasts — pick a topic on the left and its full breakdown loads here: the mental model, ERDs and worked schemas, trade-offs, edge cases, and the decisions that separate a durable model from a fragile one.

⏱ 18 min readTopics chapter readerLevel · Dimensional & Warehouse
01 · Orientation

What You'll Master Here

Inmon = integrate first (normalized core), then mart. Kimball = mart first (dimensional bus), integrate via conformed dims. Vault = insulate raw (hubs/links/sats), then mart.

⏱ 4 min · Topic 1 of 7

So far you have designed individual stars, facts and dimensions. This chapter zooms out to the architecture question: how is the whole warehouse organized? Three schools answer it — Inmon’s normalized corporate core, Kimball’s dimensional bus (what the last four chapters were built in), and Data Vault’s insulated, auditable raw layer.

Step through the decision log below first. It is one warehouse programme taking all three answers in fourteen months, with the bill each one came with. That is the judgment this chapter is for: matching an approach — usually a deliberate blend — to a team, a set of sources, and a compliance context.

Core mental model

Inmon = integrate first (normalized core), then mart. Kimball = mart first (dimensional bus), integrate via conformed dims. Vault = insulate raw (hubs/links/sats), then mart.

Why it matters

The architecture choice shapes how fast you deliver, how well you handle change and audit, and how teams collaborate. Picking dogmatically (or by accident) leads to warehouses that are slow to build or impossible to govern.

Inmon (CIF)
A top-down, normalized enterprise data warehouse feeding dependent dimensional marts.
Kimball
A bottom-up set of dimensional stars integrated by conformed dimensions (the bus).
Data Vault
An auditable, source-resilient raw layer of hubs, links, and satellites, with marts on top.
data mart
A subject-area, query-friendly model (usually dimensional) served to business users.
One warehouse, three architecture decisionsA three-site museum group loads ticketing, membership, and the gift-shop till.
Month 2 · the first star

Build one dimensional star straight off the ticketing export.

  • What was built · fact_ticket_sale, dim_date, dim_exhibition — three objects, one source system, no integration layer of any kind.
  • What it bought · A trustee-facing attendance dashboard six weeks after kickoff, while the programme still had goodwill.
  • What it cost · Month 7: the membership team ships its own mart and reports 4,120 “visitors” where ticketing reports 9,880. Neither is wrong — one counts member households, one counts admissions — but no layer anywhere in the warehouse had ever been asked to reconcile the two sources, so there is no place to go and settle it.
Where integration happens1/3
  • Month 2: Nowhere yet
    3 objects
  • Month 7: —
    not yet taken
  • Month 14: —
    not yet taken
None of these three decisions was wrong for its month. Each was a trade of speed against consistency against resilience — which is the only thing the three methodologies actually argue about.
Common mistake

Treating one methodology as universally "the right way". You force a poor fit, e.g. a heavyweight Inmon build where a quick Kimball star was needed, wasting months.

Better habit

Choose architecture by context, not by ideology.

Know what each approach optimizes for and costs.

Expect to blend approaches rather than pick one purely.

The big idea

These are not competing products; they are answers to "where does integration happen?" Inmon integrates in a normalized core, Kimball in conformed dimensions, Vault in an insulated raw layer.

Remember this

Three architectures (Inmon, Kimball, Data Vault) answer "how is the whole warehouse organized?"; mastery is matching the approach, or a blend, to your context.