Inmon vs Kimball: what to say on a DE interview
Contents:
Why this question still shows up
Almost every mid-to-senior Data Engineer loop has one DWH-design question, and the cleanest framing is Inmon vs Kimball. It is not a trivia check — interviewers want to see whether you understand why a payments team at Stripe might pick a heavy normalized hub while a growth team at DoorDash will ship a star schema in two weeks. The answer is rarely "pick one." It is "pick the one that matches the regulatory pressure, the time-to-value bar, and the query engine you are stuck with."
If you are interviewing for a platform team at Snowflake, Databricks, or a fintech that talks to auditors, you must be able to defend a 3NF enterprise warehouse. If you are interviewing for a product-analytics shop at Notion or Linear, you must defend conformed dimensions and star schemas without sounding like it is 2004. Senior loops will push further: hub-and-spoke variants, when Data Vault 2.0 wins, how the lakehouse blurs the line.
The 60-second answer: Inmon is top-down (normalize the enterprise, then build marts). Kimball is bottom-up (build marts on conformed dims, the warehouse emerges from the bus matrix). Most 2026 stacks use a medallion compromise on top of Iceberg or Delta.
This article is the long version of that 60-second answer — the version that survives follow-up questions.
Inmon: top-down EDW
Bill Inmon, often called the father of the data warehouse, defined the warehouse as subject-oriented, integrated, time-variant, and non-volatile. In his world you build the Enterprise Data Warehouse (EDW) first — a single normalized 3NF store that becomes the source of truth for every domain. Only after the EDW exists do you carve denormalized data marts for finance, marketing, or product, each tuned for fast reads.
The mental model is a hub-and-spoke: one normalized hub, many star-shaped spokes. Marts are derivations of the EDW, never sources of their own. Reconciliation happens upstream, in the hub, not in BI dashboards. That is the whole point — when an auditor asks "why does revenue in dashboard A differ from dashboard B," the Inmon answer is "it can't, by construction."
Where it wins. Large regulated enterprises with multi-year horizons: banks, insurers, healthcare, anyone with an integrated risk model or an external audit trail. If your loss event has to tie out to the same customer record three departments use, you want one canonical customer entity, not three slightly different ones living in separate marts.
Where it loses. Time-to-value. A pure Inmon EDW often takes 12-24 months before a stakeholder sees a dashboard. In a startup that horizon kills the project. And in 2026 the cost case for 3NF is weaker than it was in 1992 — cheap columnar storage means denormalization is no longer a luxury.
Kimball: bottom-up marts
Ralph Kimball flipped the order. Start with the business process — orders, sessions, support tickets — and build a data mart with a fact table per process surrounded by dimension tables. The warehouse is not a separate artifact; it is the union of all your marts, held together by conformed dimensions: shared, agreed-on dim_customer, dim_product, dim_date that look identical across every mart.
The planning artifact is the bus matrix: a grid where rows are business processes (orders, payments, returns) and columns are dimensions (customer, product, store, date). A cell is checked if that process uses that dim. The matrix forces the team to commit to dimensions before the marts ship, which is what keeps the warehouse from devolving into siloed spreadsheets.
Where it wins. Product companies that need to ship insight in weeks, not quarters. Star schemas are also a natural fit for columnar OLAP engines — BigQuery, Snowflake, Redshift, ClickHouse — where wide denormalized facts beat normalized joins by an order of magnitude on real workloads.
Where it loses. Without a disciplined bus matrix, conformed dimensions drift. Marketing's dim_user slowly diverges from product's dim_user, and six months later nobody trusts the join. This is the failure mode senior interviewers will probe — they want to hear you mention conformed dims unprompted.
Side-by-side comparison
The textbook table, with the numbers that actually matter on an interview:
| Dimension | Inmon (top-down) | Kimball (bottom-up) |
|---|---|---|
| Build order | EDW first, then marts | Marts first, warehouse emerges |
| Core model | 3NF in EDW, star in marts | Star schema with conformed dims |
| Time to first dashboard | 6-12+ months | 1-3 months per mart |
| Total runway to "done" | 18-36 months | Incremental, never done |
| Up-front cost | High (modeling + ETL) | Medium (per-mart) |
| Source of truth | The EDW itself | Conformed dimensions across marts |
| Adding a new source | Hard — touches the hub | Easy — new mart, reuse conformed dims |
| Best query engine | Row-store RDBMS historically | Columnar (BQ, Snowflake, Redshift) |
| Audit friendliness | Excellent | Good if discipline holds |
| Typical employer | Banks, insurers, healthcare | Product, retail, ad-tech |
A useful framing for the interviewer: Inmon optimizes for correctness at the cost of speed; Kimball optimizes for speed at the cost of governance. Neither is wrong, both have failure modes.
The medallion compromise
Most cloud stacks built after 2020 do not pick. They run a medallion architecture — three layers, each borrowing from a different school:
- Bronze — raw ingest, append-only, minimal transformation. Closest analog: Inmon staging.
- Silver — cleaned, deduplicated, conformed entities. Close to an Inmon EDW but not strictly 3NF.
- Gold — business-facing marts, often star or wide-denormalized tables. Pure Kimball.
Load-bearing trick: medallion is not a Kimball-vs-Inmon truce, it is a cost optimization. Cheap object storage means you can keep bronze forever, so re-deriving silver and gold becomes a Spark job, not a multi-year project.
This works because the cost curve flipped. In 1992, storage was expensive and 3NF saved money; in 2026, storage is free and compute is cheap, so denormalizing into gold marts is the rational move. The silver layer gives you the single source of truth Inmon insists on, while gold gives you the fast dashboards Kimball promised.
What modern teams actually pick
A rough taxonomy, useful for the "what would you do at company X" follow-up:
- Banks, insurers, regulated fintechs (Stripe risk, JPMC, Block). Lean Inmon or Data Vault 2.0 in the canonical layer, Kimball-style marts for BI. Audit trail is non-negotiable.
- Consumer-product companies (DoorDash, Uber, Airbnb, Notion). Kimball-flavored medallion on Snowflake or Databricks. Star schemas in gold, conformed dims maintained by a small platform team.
- Streaming-heavy stacks (Netflix, observability companies). Medallion on Iceberg or Delta Lake, with dbt materializing the gold layer. Often no explicit "EDW" name — the silver layer plays that role.
- AI-native companies (OpenAI, Anthropic, Vercel). Lighter touch: a lakehouse, a feature store, and a few gold marts for finance and growth. Pure Inmon would be malpractice at their pace.
- Government, healthcare, regulated state-owned utilities. Still mostly Inmon with vendor DWH (Teradata, Oracle Exadata, on-prem Snowflake).
Compensation note for context: US Data Engineer L4/L5 base ranges roughly $160k-$220k at FAANG-adjacent companies, with total comp $230k-$380k including stock — and the loop almost always has one modeling question of exactly this shape. levels.fyi confirms the spread.
Common pitfalls
The single biggest mistake is defaulting to a pure Inmon EDW on a 6-person startup team. It sounds rigorous in an architecture review but it ships nothing. The fix is to start with one Kimball-style mart on the noisiest business process — usually orders or sessions — and let the warehouse emerge. You can always normalize backward later; you cannot un-spend a year of engineering on a hub nobody queries.
The opposite failure is calling Kimball outdated because it is from 2002. Star schemas are more relevant in 2026 than they were then, because columnar engines (Snowflake, BigQuery, ClickHouse) are explicitly tuned for wide fact tables joined to small dimensions. Saying "we don't use Kimball, we use dbt" misses the point — most well-run dbt projects are Kimball with conformed dimensions and a bus matrix, just renamed.
Another trap is shipping marts without conformed dimensions. The marketing team builds dim_user from raw events, the product team builds it from the billing service, and within a quarter the two definitions disagree on what an "active" user is. The fix is unglamorous: a small platform team owns the conformed dims, every mart imports them, and definition changes go through review. Without this discipline, Kimball collapses into a pile of dashboards.
A more technical one: building a 3NF EDW on ClickHouse. ClickHouse is excellent for wide denormalized analytics but its join performance is mediocre by design — the engine assumes you pre-joined upstream. A normalized hub here will run slower than a denormalized gold table by a factor of 10-100x on typical workloads. The fix is to keep the silver layer in something that joins well (Snowflake, BigQuery, Postgres) and push only gold into ClickHouse.
Finally, ignoring slowly changing dimensions (SCD) in either approach. Both Inmon and Kimball require an explicit decision about how to historize dimension changes — Type 1 (overwrite), Type 2 (new row with effective dates), or hybrid. Skipping SCD in interviews is a fast way to look junior, because cohort analysis breaks the moment a customer's plan changes and you forgot to keep history.
Related reading
- DWH modeling on a DE interview
- DWH layers explained for DE
- ClickHouse as a DWH
- Data Vault 2.0 deep dive
- dbt mart best practices
- SQL for Data Engineer interviews
If you want to drill DE modeling questions like this every day, NAILDD is launching with 500+ interview problems across SQL, modeling, and pipeline design.
FAQ
Which approach does Snowflake or BigQuery favor?
Both are columnar engines tuned for wide fact tables joined to a handful of dimension tables, which is exactly the Kimball star schema shape. Most teams on Snowflake or BigQuery end up running a medallion stack with a Kimball-flavored gold layer — sometimes augmented by a Data Vault raw layer if regulatory pressure justifies it. Pure normalized Inmon on these engines is technically possible but usually wastes their architectural advantage.
What is a conformed dimension, in one paragraph?
A conformed dimension is a dimension table that is byte-for-byte identical across every mart that uses it — same surrogate keys, same attribute names, same business definitions. The classic example is dim_date: it should not exist in two slightly different forms in two marts, because every cohort and retention metric joins to it. Conformed dims are what turn a collection of marts into a warehouse rather than a graveyard of spreadsheets.
Is Data Vault 2.0 an Inmon or Kimball variant?
Neither. Dan Linstedt's Data Vault 2.0 is a third approach built around hubs (business keys), links (relationships), and satellites (descriptive attributes with history). It is more normalized than Kimball but more flexible than Inmon, and it shines when source systems change frequently and you need a fully auditable raw layer. Most teams that adopt it use it for the silver-equivalent layer and still ship Kimball-style gold marts on top.
Should I memorize the original Inmon and Kimball books?
Skim them. Inmon's Building the Data Warehouse (1992) and Kimball's The Data Warehouse Toolkit (2002, with later editions) are still worth a weekend, but no interviewer will quiz you on chapter numbers. What they will probe is whether you can articulate the trade-offs without name-dropping — if you can explain why a regulated fintech leans Inmon and a consumer app leans Kimball, you have the working knowledge that matters.
How does the lakehouse change the answer?
The lakehouse (Iceberg, Delta Lake, Hudi on cheap object storage) collapses the storage-vs-compute trade-off that made Inmon attractive in the first place. When storage is effectively free and compute is on-demand, you can keep raw bronze forever, rebuild silver on a schedule, and let gold marts churn weekly without the cost panic of 1990s on-prem DWH. The practical effect is that medallion-on-lakehouse has become the default for any greenfield 2026 build, with Kimball patterns dominating the gold layer.