# Kimball vs Inmon vs Data Vault

> The three classic warehouse design approaches, what each optimises for, and how modern teams combine them.

- Source: https://akshaythakare.com/notes/data-warehousing/kimball-inmon-data-vault
- Topic: Data Warehousing
- Level: intermediate
- Reading time: 2 min
- Tags: data-warehousing, data-modeling, architecture, interview
- Updated: 2026-10-11

## Three approaches

| | Kimball | Inmon | Data Vault |
| --- | --- | --- | --- |
| Core idea | Dimensional models per business process | Normalized enterprise warehouse first, marts after | Hubs, links and satellites that record history |
| Delivery | Fast, incremental | Slower, centralised | Flexible integration layer |
| Strength | Easy for analysts and BI | Single integrated source of truth | Auditable, handles changing sources |
| Weakness | Conformance takes discipline | Big upfront design | Not query-friendly; needs marts on top |

## Kimball in one picture

```text
dim_date   dim_store
     \       /
      fact_sales  — one row per order line
     /       \
dim_product  dim_customer
```

Conformed dimensions (the same `dim_customer` everywhere) let facts from different processes be compared.

## Data Vault in one picture

```text
hub_customer (business key) ── link_order_customer ── hub_order
      |                                                  |
sat_customer_details (history)               sat_order_status (history)
```

Hubs hold keys, links hold relationships, satellites hold descriptive attributes with load timestamps. New sources add satellites without changing existing tables.

## What teams do today

A common lakehouse stack mixes them: a raw/bronze layer, an integrated and historised layer (sometimes Data Vault), and **Kimball-style marts** for consumption.

> **Tip: Interview framing**
>
> "For BI I model Kimball star schemas. When many changing sources need auditable history, a Data Vault integration layer underneath can help — but marts still serve the queries."