Kimball vs Inmon vs Data Vault 2.0: Choose Like an Architect, Not a Fanboy
If you've spent more than five minutes in data warehousing, you've seen it:
- Someone says "Kimball is dead, cloud fixes everything."
- Someone else says "Inmon is the only serious enterprise architecture."
- A third person slides in with "Data Vault 2.0 is the future—just add Hubs, Links, Satellites and boom: audit-ready agility."
And then… nothing gets built for six weeks. Everyone shows up with a favorite methodology, a few conference slides in their head, and one dangerous sentence: "We should standardize on the right approach."
Here's my promise: this post will help you pick an approach the way an architect picks a structure—not like a sports fan picking a jersey .
Kimball, Inmon, and Data Vault 2.0 are not three rival religions. They are three different answers to one architectural question:
Where do I want the pain to live?
- In the reporting layer, so business users get answers fast?
- In the enterprise integration layer, so the company has one governed backbone?
- In a historized core, so source chaos and audit pressure stop breaking the model?
The “methods” differ mostly in which job they optimize first.
At the highest level, every analytical data platform is trying to do three jobs:
- Capture what happened (reliably and repeatably).
- Integrate it into shared meaning (so “customer” isn’t five different creatures).
- Serve it to humans and machines (fast, consistent, explainable).
If you only remember one thing, make it this:
These are not three competing “database shapes.”
They’re three different answers to: “Where do we put integration, and when do we pay for it?”
That’s why the debates get heated: teams are arguing about when to do hard work, not whether the hard work exists.
Before arguing about modeling philosophy, you need to understand the reality you're dealing with. That's what we invented TalkingSchema for, to explore the mess - which system owns customer identity, which system owns money, which table lies by omission, and where the business keeps asking questions the source systems were never designed to answer.
I’ll show you what that looks like, not from a whiteboard in a vacuum, but from source systems outward.
The source-system reality I start with
Here’s the source schema I mapped in TalkingSchema before touching any architectural decision. I recommend spending a moment with the ERD, and read the DBML notes. Understand the actual mess we’re designing for.
Imagine I'm building analytics for a mid-market commerce company. Nothing exotic. Just enough complexity to hurt.
Customer identity lives in crm.customers. Orders live in sales.orders and sales.order_items. Payments live in billing.payments. Shipments live in fulfillment.shipments. Inventory snapshots live in inventory.stock_snapshots. Marketing insists promo logic matters, so now we also have marketing.promotions and marketing.order_promotions.
Source schema
This is where methodology debates should begin: with the actual systems. Not with the end-state diagram people want to show at a meetup.
Three methodologies, one same reality
Now comes the part people usually overcomplicate.
We're still modeling the same business. Customers buy products. Orders create revenue. Payments settle money. Shipments move goods. Inventory changes over time.
What changes is which question I optimize first.
Kimball: “Make the business question easy”
Inmon: “Integrate the enterprise before you decorate it”
Data Vault 2.0: “Assume change is the normal state”
Let's dive deep on each;
Architecture Deep Dives