Kimball and Inmon represent two foundational philosophies for data warehouse design. Kimball is bottom-up, dimensional, and fast-to-value. Inmon is top-down, normalised, and enterprise-integrated. Here is how to choose — and why the modern data stack has changed the decision.
The quick answer
Kimball and Inmon are the two foundational data warehouse design methodologies. Kimball is dimensional modelling: fact tables and dimension tables designed directly for business user queries, built bottom-up from specific analytical requirements. Inmon is normalised modelling: a central enterprise data warehouse in third normal form (3NF), built top-down from an enterprise data model, with separate data marts for reporting.
In practice: Kimball is faster to deliver value, more analyst-friendly, and the dominant approach in modern analytics. Inmon is more complex to build and maintain but produces a more rigorous, enterprise-integrated data model. Most organisations choosing a data warehouse approach today land closer to Kimball — and the modern data stack (dbt on Snowflake/BigQuery) makes dimensional modelling the natural pattern.
The Kimball approach
Ralph Kimball's dimensional modelling methodology, documented in "The Data Warehouse Toolkit" (1996, updated through 2013), organises warehouse data into fact tables and dimension tables.
**Fact tables** contain the quantitative measures of business events: order amounts, page views, transaction amounts, call durations. Each row represents a specific event or period measurement. Fact tables are narrow (many rows, fewer columns) and are the primary objects that analytical queries aggregate.
**Dimension tables** contain the descriptive attributes of facts: customer name, product category, sales territory, date properties. Dimension tables are wide (fewer rows, many columns) and provide the filter, grouping, and drill-down context for fact queries. The canonical example: a star schema with a fact_sales table in the centre, surrounded by dim_customer, dim_product, dim_date, and dim_store dimension tables.
The **star schema** is the core Kimball pattern: one fact table, multiple dimension tables, no joining between dimension tables. The **snowflake schema** is a variation where dimension tables are normalised into sub-dimensions (dim_product splits into dim_product + dim_product_category + dim_product_subcategory). Snowflake schema reduces some storage redundancy at the cost of query complexity.
**Slowly Changing Dimensions (SCDs)** handle the practical problem of dimensions that change over time: a customer moves from London to Manchester; a product changes category; a salesperson moves territory. Kimball defined multiple SCD types for preserving or overwriting historical values, the most common being SCD Type 1 (overwrite — history is lost), SCD Type 2 (insert a new row with effective dates — history is preserved), and SCD Type 3 (add a "previous value" column — limited history).
Kimball's approach is **bottom-up**: you build the first data mart for the highest-priority business question, then build additional marts for subsequent requirements. Business value is delivered incrementally. The enterprise data warehouse emerges from the assembly of conformed dimensions and facts across data marts, rather than being defined upfront.
The Inmon approach
Bill Inmon's enterprise data warehouse methodology, documented in "Building the Data Warehouse" (1992, updated through 2005), defines a data warehouse as: "a subject-oriented, integrated, non-volatile, and time-variant collection of data in support of management's decision making process."
The Inmon approach builds a **corporate information factory (CIF)**: a central, normalised (third normal form) enterprise data warehouse that integrates all business subjects, from which separate dimensional data marts are created for reporting.
Third normal form (3NF) means data is fully normalised: no redundancy, atomic attributes, no repeating groups. A customer record appears once; all customer orders reference that single customer record by key. This is how operational databases (OLTP) are typically designed, and Inmon's EDW uses the same pattern.
The Inmon EDW is **top-down**: the enterprise data model is defined first — what are the core business entities? How do they relate? — before any specific data mart is built. The upfront investment in the enterprise model produces a coherent, integrated foundation, but delivery of first business value takes longer than Kimball's bottom-up approach.
Data marts are built on top of the EDW: summary and dimensional structures that users and BI tools query. In Inmon's model, the 3NF EDW is not what analysts query directly; it is the clean, integrated data store from which dimensional data marts are derived.
Head-to-head comparison
**Speed to first value.** Kimball wins clearly. Building a first Kimball star schema — one fact table, key dimensions, connected to a BI tool — can be accomplished in weeks. Building an Inmon EDW requires defining the enterprise data model before building anything; this upfront design phase takes months. For organisations under pressure to deliver analytics value, Kimball's bottom-up approach is significantly faster.
**Query performance.** Kimball wins for typical BI queries. Star schemas are optimised for analytical queries: the denormalised dimension tables reduce join depth, and modern columnar warehouses (Snowflake, BigQuery) are specifically optimised for the aggregation patterns of star schema queries. Inmon 3NF structures require more joins per query, which adds complexity and latency for BI workloads.
**Data integration across subjects.** Inmon wins. The 3NF EDW integrates all business subjects in a single, normalised model. Customer data, order data, product data, and financial data all reference the same master entities. Cross-subject analysis (revenue by customer segment by product category by territory) reads from a clean, integrated model. Kimball's conformed dimensions achieve integration across data marts, but require discipline to maintain conformed definitions — and in practice, large Kimball implementations often develop inconsistencies between marts that were built by different teams at different times.
**Maintenance complexity.** Inmon requires more upfront design but is more maintainable for large, complex enterprise environments. A well-designed 3NF EDW accommodates new requirements by adding tables and relationships without restructuring existing ones. Kimball data marts can be simpler to maintain individually but become complex to maintain as a whole when many marts with shared but independently-evolved dimensions exist.
**Analyst accessibility.** Kimball wins significantly. Business analysts understand dimensional models intuitively — "show me revenue (fact) by customer (dimension) by month (date dimension)" maps directly onto a star schema query. 3NF EDW structures are not designed for direct analyst use; they require the mediating data mart layer and typically SQL expertise to navigate.
**Modern data stack fit.** Kimball wins. The medallion architecture used in modern data stacks — Bronze/Silver/Gold layers — maps naturally onto Kimball: the Gold layer is dimensional tables designed for consumption. dbt's mart models follow dimensional modelling conventions. BI tools (Tableau, Power BI) are optimised for star schema patterns. For organisations building on Snowflake, BigQuery, or Databricks with dbt, the Kimball approach is the natural pattern.
The modern synthesis
In contemporary data warehouse practice, the sharp Kimball/Inmon distinction has blurred. Most modern data architectures take elements from both:
- The **medallion architecture** (Bronze/Silver/Gold) adopts the Inmon principle of staged integration: raw data is cleaned and integrated at the Silver layer before being modelled for consumption at Gold — but the Gold layer uses dimensional modelling rather than 3NF.
- **dbt transformation patterns** often produce Silver-layer models that are closer to 3NF (normalised staging models) before producing Gold-layer dimensional models for consumption — a hybrid of both approaches.
- **Data vault modelling** (Dan Linstedt) is a third approach that separates historical loading (hubs, satellites, links) from presentation (business vault), providing Inmon-like integration properties with more agility. Data vault is used by some large enterprises but has not become the dominant pattern.
For most organisations building a new data warehouse today, the practical recommendation is: follow Kimball dimensional modelling conventions for the analytical layer (Gold/marts), with well-designed staging models at Silver that establish clean, integrated entities before dimensional models are built on them. This is what the modern dbt-based data stack produces naturally.
Which should you choose?
**Kimball-aligned dimensional modelling** is the right default for:
- Mid-market organisations building a data warehouse for the first time
- Organisations under pressure to deliver analytical value quickly
- Teams using dbt on a modern cloud warehouse (Snowflake, BigQuery, Databricks)
- Environments where analyst self-service is important
- Most analytics use cases
**Inmon-aligned enterprise data warehouse** is worth considering for:
- Very large enterprises with complex, multi-domain integration requirements
- Organisations where the primary requirement is operational data integration across many source systems, not just analytics
- Environments with strict regulatory requirements for data lineage and auditability in the integration layer
- Organisations with a large, experienced data architecture team that can execute the upfront design investment
In most cases, if you are choosing a data warehouse modelling approach in 2026, you are building on a modern cloud platform with dbt, and the answer is dimensional modelling with a well-structured Silver layer — the modern synthesis, not a pure Kimball or Inmon implementation.
For the data warehouse architecture context, see what is a data warehouse. For how the medallion architecture implements these patterns in the modern data stack, see what is a data lakehouse. For the transformation tooling that implements these models, see what is dbt.
Our data architecture consulting practice designs data warehouse schemas and transformation architectures for mid-market and enterprise organisations. If you are designing a new data warehouse or evaluating the design of an existing one, book a free 30-minute audit for a direct assessment.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →