Why Dimensional Modelling Isn't Dead—It's Just Getting Started

Chris Hillman — Fri, 07 Nov 2025 09:00:00 +1100

The Great Data Modelling Debate Nobody Asked For

Another meeting where someone confidently declared, “We don’t need data modelling anymore—just dump everything in the data lake and let analysts figure it out.”

I’ve heard variations of this statement for years now, in meetings or at conferences. The pitch is always the same: traditional data warehousing is dead, dimensional modelling is a relic from the 90s, and modern big data tools have made structured modelling obsolete. Schema-on-read is the future. Agility over architecture.

You know what’s fascinating? The people making these arguments usually end up drowning in a data swamp they can’t navigate.

Here’s the thing nobody wants to admit: dimensional modelling isn’t dead—it’s more widely used than at any other point in history. Ralph Kimball’s methodology from 1996 now powers over 90% of enterprise data warehouses, delivering measurable ROI of 401% over three years. Companies from Uber (managing 100+ petabytes) to Netflix, Airbnb, and Spotify continue betting on dimensional approaches because they deliver what actually matters: fast queries, consistent metrics, and analytics that business users can understand.

The debate isn’t whether to model data. It’s how to adapt proven principles to modern platforms.

Let me show you why.

The Fundamentals That Refuse to Die

Ralph Kimball introduced dimensional modelling to the data warehousing world in 1996 with “The Data Warehouse Toolkit,” which became the definitive guide for organising analytical data. The methodology centres on a deceptively simple four-step process: select the business process, declare the grain, identify the dimensions, and identify the facts.

This framework emerged from Kimball’s background in human-computer interaction at Xerox PARC, where he helped design the Star Workstation—the first commercial product using mice, icons, and windows. His insight wasn’t just about database structure. It was about how humans naturally think about business measurements.

The brilliance lies in a fundamental division: separate measurements from context. Facts are numeric measurements taken repeatedly from business processes—sales amounts, quantities, durations. Dimensions provide the “who, what, where, when, why, and how” context surrounding those measurements. This creates star schemas where a central fact table connects to surrounding dimension tables, resembling a star when visualised.

The denormalised structure deliberately relaxes traditional database normalisation rules to optimise for analytical queries rather than transactional updates. And that’s where the magic happens.

Star schemas deliver concrete performance advantages. According to the official Kimball methodology documentation, the benefits include simpler queries compared to highly normalised schemas, simplified business reporting logic, query performance gains for read-only applications, and fast aggregations. The flat, denormalised dimension tables are perfect targets for bitmap indexes, while star-join optimisations built into modern database engines can process these patterns efficiently.

Kimball explicitly warns against snowflaking dimensions into third normal form because it “destroys the ability to use bitmap indexes and increases the user-perceived complexity of the design.” When you’re trying to answer business questions quickly, that complexity tax adds up fast.

The Integration Secret: Conformed Dimensions

Here’s where dimensional modelling gets really powerful—and where most data lakes completely fall apart.

Conformed dimensions represent the integration backbone of enterprise data warehousing. When dimension tables share identical column names and domain contents across different fact tables, they enable “drilling across”—combining information from separate business processes in unified reports.

Think about it this way: a date dimension conforms across sales, inventory, and customer service. A product dimension spans sales, procurement, and manufacturing. As the Kimball Group states: “This is the essence of integration in an enterprise DW/BI system. Conformed dimensions, defined once in collaboration with the business’s data governance representatives, are reused across fact tables; they deliver both analytic consistency and reduced future development costs because the wheel is not repeatedly re-created.”

I can’t tell you how many teams I’ve seen struggle because they have five different “customer” definitions, three different ways to calculate “revenue,” and no standard date dimension. Every analyst builds their own version. Every report uses slightly different logic. Nobody trusts the numbers because they never match.

Conformed dimensions solve this. Once. Properly. Forever.

Slowly Changing Dimensions: The Time Machine Nobody Talks About

One of the most elegant solutions in dimensional modelling addresses a tricky problem: how do you track attributes that change over time?

Slowly Changing Dimensions (SCDs) handle this challenge through several type patterns:

Type 0: Preserves original values that never change
Type 1: Overwrites old values, destroying history but remaining simple
Type 2: Adds new rows with new surrogate keys whenever attributes change, preserving complete historical accuracy through row effective dates, expiration dates, and current row indicators
Type 3: Adds columns for alternate reality comparisons
Types 4-7: Hybrid approaches for rapidly changing attributes or dual historical/current perspectives

Type 2 is the most common approach, and for good reason. It enables time-variant analysis while maintaining referential integrity between facts and dimensions. You can answer questions like “what was this customer’s address when they placed that order three years ago?” without complex joins or temporal logic in every query.

Try doing that efficiently in a schema-on-read data lake without proper modelling. I’ll wait.

The Performance Numbers That Matter

Let’s talk about actual performance, because that’s where the rubber meets the road.

Apache Doris demonstrated 31x performance improvement on Star Schema Benchmark (SSB) queries between versions. StarRocks proved 4.75x faster than Apache Druid and 1.87x faster than ClickHouse on 100GB datasets. Most queries complete under 200 milliseconds, with Apache Kylin achieving O(1) constant-time query latency regardless of data size.

Academic research on distributed dimensional data warehouses shows materialised views can reduce query processing time by 89-98% with only 13% disk space overhead.

But performance isn’t just about milliseconds. McKinsey Global Institute research reveals the business impact: retailers using big data to the full have potential to increase operating margins by more than 60%. Organisations leveraging data-driven approaches are 23 times more likely to acquire customers, 6 times more likely to retain customers, and 19 times more likely to be profitable.

These aren’t small companies or theoretical studies. McKinsey examined five domains globally including healthcare, retail, manufacturing, and public sector organisations.

The Hidden Tax of Bad Data

Here’s what nobody tells you about skipping data modelling: you pay for it anyway, just later and more expensively.

Gartner research shows organisations lose an average of $12.9 million annually due to poor data quality. IBM estimates US businesses lose $3.1 trillion collectively. The Wakefield Research survey found over 50% of respondents indicated 25% or more of their revenue was affected by data quality issues.

The 1x10x100 Rule quantifies escalating remediation costs: fixing a data quality issue at point of entry costs 1x, fixing after it propagates within systems costs 10x, and fixing after it reaches end-users and decision-making costs 100x.

Let me give you some real-world disasters:

Unity Software lost $110 million in revenue and $4.2 billion in market cap in 2022 from ingesting bad data from a large customer, causing 37% drop in share price and loss of investor confidence.

Samsung Securities suffered a $300 million “fat-finger” error when an employee mistakenly paid 1,000 shares instead of 1,000 won per share in dividends, issuing $105 billion worth of shares before correction.

Equifax sent lenders inaccurate credit scores on millions of customers due to coding issues, dropping stock 5% and triggering class-action lawsuits.

JPMorgan Chase’s “London Whale” incident lost $6.2 billion, exacerbated by errors in risk models relying on flawed data.

NASA’s Mars Climate Orbiter burned $125 million due to unit mismatches between metric and imperial measurements.

These aren’t abstract warnings. They’re real money disappearing from real balance sheets.

The Productivity Drain Nobody Measures

Want to know where your data team’s time actually goes?

Data scientists and analysts spend 60% of their time cleaning and organising data according to Forbes analysis, with 19% more spent searching for information. Anaconda’s State of Data Science surveys consistently show 39-45% of time on data preparation tasks rather than actual analysis.

An IDC report found 44% of data workers’ time is wasted on unsuccessful activities, with 33% (12.5 hours weekly) spent preparing information and 15% searching for data. For a team of 10 analysts, this represents 8,900+ hours of lost productivity annually.

Think about that. Your highly skilled analysts—the people you hired to generate insights—are spending half their time just trying to figure out what the data means and how to structure it for analysis.

Dimensional modelling solves this because the structure itself communicates meaning. An analyst looks at a star schema and immediately understands: here are the measurements, here’s the context, here’s how they relate. The modelling work gets done once by experts, then leveraged by everyone. It follows that DRY mantra of programming for years - Don’t Repeat Yourself.

The Inconsistent Metrics Problem

This is the silent killer of data team credibility.

When three different tables represent the same business entity with different SQL logic, two analysts answering identical questions produce different results. Stakeholders lose confidence. Executive meetings devolve into debates where one department reports growing customer base while another reports increased churn.

Simple metrics like Daily Active Users or Revenue get calculated differently by different teams. One defines DAU as logins, another as specific actions, a third as time spent—each producing wildly different results.

Years back I was in a meeting where 2 GM’s literally argue about whether revenue is up or down because they’re looking at reports built on different data models (different teams data) with different business logic. The data team ends up spending hours reconciling numbers instead of generating insights.

Conformed dimensions and standardised fact tables eliminate this problem. There’s one product dimension. One customer dimension. One date dimension. One revenue fact. When everyone queries the same well-modelled tables, everyone gets the same answers.

Real Companies, Real Scale, Real Results

Let’s look at organisations actually doing this at scale.

Uber’s Global Data Warehouse

Uber’s data lake consists of “foundational fact, dimension, and aggregate tables developed using dimensional data modelling techniques” accessible to engineers and data scientists in a self-serve manner.

The scale is staggering:

100+ petabytes of data in HDFS
100,000 vcores in compute cluster
100,000 Presto queries per day
10,000 Spark jobs per day
20,000 Hive queries per day

Their incremental ETL approach using Apache Hudi delivered 50% decrease in pipeline run time and 60% decrease in SLA, supporting minute-level latency for petabyte-scale data.

As Uber’s engineering blog states directly: “The data lake consists of foundational fact, dimension, and aggregate tables developed using dimensional data modelling techniques that can be accessed by engineers and data scientists in a self-serve manner to power data engineering, data science, machine learning, and reporting across Uber.”

Netflix’s Unified Data Architecture

Netflix integrates dimensional models for operational reporting while managing data from 500+ microservices globally. Their data warehouse built on Apache Iceberg tables uses GraphQL integration with knowledge-graph-based design for consistent data modelling.

This powers Sphere, Netflix’s self-service operational reporting tool for business users, handling multiple petabytes of data. The architecture demonstrates dimensional modelling works seamlessly with modern streaming and microservices architectures.

Spotify’s Event Processing

Spotify processes 500 billion events per day (70TB compressed daily) running 20,000 batch data pipelines across 1,000+ repositories. Their Google Cloud Platform implementation uses BigQuery for dimensional models supporting podcast analytics and business reporting.

The company attributes 75% year-over-year ad revenue growth to data-driven insights enabled by their dimensional data architecture.

Airbnb, Facebook, and Lyft’s Snapshot Approach

These companies pioneered snapshot-based dimensional modelling, a technique developed by Maxime Beauchemin (senior Lyft data engineer) that modernizes slowly changing dimensions for cloud environments.

Rather than complex SCD Type 2 logic, they create daily or weekly table partitions as snapshots of dimensional data, leveraging cheap cloud storage. Beauchemin’s philosophy: “Compute is cheap. Storage is cheap. Engineering time is expensive.”

This pragmatic adaptation of Kimball principles for cloud-native environments exemplifies how dimensional modelling evolves without abandoning core principles.

The Healthcare and Finance Proof Points

Want proof dimensional modelling works in regulated environments with strict compliance requirements?

Piedmont Healthcare manages 15 TB of data from 16 hospitals and 1,400 physician practices serving 2+ million patient visits annually. Their migration to Exasol with dimensional models reduced dashboard refresh time from 10 minutes to seconds while delivering 20 new metrics per month.

Kaiser Permanente’s HealthConnect integrates millions of patient records using dimensional models, enabling reduced hospital stays through early risk identification and improved chronic disease management. These implementations prove dimensional modelling satisfies stringent HIPAA and regulatory requirements while delivering performance.

JPMorgan Chase uses sophisticated dimensional data warehouse infrastructure for risk management, regulatory compliance, and personalized banking experiences.

Target Corporation’s Guest Data Platform integrates dimensional models for unified customer views, powering highly successful personalized marketing campaigns and optimised store layouts.

The ROI Study That Ends the Debate

An International Data Corporation study of 62 organisations documented average ROI of 401% over three years, excluding failed projects and extreme outliers.

Common metrics show:

Payback periods of 1-3 years
Positive net present value in 75%+ of implementations
15-30% reduction in operational costs
10-25% increase in data-driven revenue opportunities

These aren’t theoretical benefits. They represent measured outcomes from actual enterprise implementations.

Meanwhile, industry adoption rates paint a clear picture: 90%+ of enterprises globally utilise data warehousing infrastructure, with 58% of deployments cloud-based. The data warehousing market reached $34.5-35 billion in 2024, projected to grow to $75-93 billion by 2033.

Joe Reis, prominent data engineering consultant, observes: “Kimball is more in use than any other point in time due to being the default way to model data in Self-Service Business Intelligence applications (BI): Power BI and Tableau. And BI is 10 times bigger in usage than data engineering.”

Modern Platforms Embrace Dimensional Modelling

Here’s where the “dimensional modelling is dead” crowd gets it completely wrong. Modern cloud platforms haven’t replaced dimensional modelling—they’ve made it easier to implement.

Snowflake’s Explicit Recommendation

Snowflake’s official blog states: “When using Snowflake, store the raw data history in a structured or variant format, clean and fit the data using the third normal form or the Data Vault model, and it makes sense to store the final consumable data in the Kimball dimensional data model.”

The company notes each data model has advantages and “storing intermediate step results has significant architectural advantages.” Snowflake’s columnar storage, automatic query optimisation for star joins, and separation of compute and storage complement dimensional designs perfectly.

Databricks’ Lakehouse Approach

Databricks’ official guidance emphasises: “A large number of our customers are migrating their legacy data warehouses to Databricks Lakehouse… As we help customers in the field, we find that many are looking for best practices around proper data modelling and physical data model implementations in Databricks. For Data Warehousing, Analytics-friendly modelling styles like Star-schema and Data Vault are quite popular.”

The lakehouse medallion architecture (Bronze/Silver/Gold layers) typically implements dimensional models in the Gold layer for business consumption. Databricks supports identity columns for surrogate keys, primary/foreign key constraints, Z-order clustering for performance, and column-level data quality constraints—all features that facilitate dimensional modelling.

BigQuery’s Optimisation

BigQuery’s architecture optimises for dimensional models. The platform’s columnar storage, partitioning, clustering, and primary/foreign key hints enable query optimisers to efficiently execute dimensional model queries. Type 2 dimension tables at the same grain as fact tables can be flattened into physical tables, while the logical model maintains clear dimensional structure.

Microsoft Fabric’s Position

Microsoft Fabric’s official documentation states unequivocally: “A star schema design is optimised for analytic query workloads. For this reason, it’s considered a prerequisite for enterprise Power BI semantic models.”

The documentation emphasises that while specific circumstances might suggest alternatives, “the theory of dimensional modelling is still relevant. That theory helps analysts create intuitive and efficient models.”

The Fortune 500 Case Study Nobody Talks About

Dustin Dorsey (Principal Data Architect at Onyx) presented at the Open Data Science Conference in April 2024, busting modern myths about dimensional modelling.

He demonstrated a Fortune 500 company using dbt and Databricks that was “drowning in complexity” with one massive dbt model containing over 1,000 lines of code.

After implementing dimensional modelling:

21 modular dbt models replaced the monolith
179 tests replaced 2
6 measurable columns replaced 1
250+ accessible attributes became available

“Analysts went from reading 1,000 lines of code to writing 20.”

Performance remained comparable but with significantly better governance, scalability, and business usability.

This is the pattern I see repeatedly: teams start with the promise of agility and flexibility, build increasingly complex models to handle reality, then eventually refactor back to proper dimensional modelling after the pain becomes unbearable.

Why not start with the proven approach?

The Technical Debt Time Bomb

McKinsey research shows organisations spend 20-40% of technology estate value managing technical debt. Stripe’s engineering study found teams spend an average of 33% of their time managing technical debt—time that could drive innovation and growth.

Database migration horror stories illustrate accumulated debt coming due. Datometry analysis shows 300-500% cost overruns are more common than expected in data warehouse migrations, with consulting fees for large migrations reaching tens of millions, sometimes exceeding $100 million for Fortune 100 projects.

Hidden costs include:

Upgrading all ETL, BI, and reporting systems simultaneously
Business disruptions lasting weeks or months
Compliance re-certification for regulated workloads
Schema mismatch analysis and transformation
Data cleansing for decades of dirty data

One mid-sized e-commerce company with approximately 50 million users attempted MySQL to MongoDB migration with fundamentally broken data modelling—trying to recreate relational tables in a document database.

Product catalog queries requiring 15+ joins saw response times balloon from 50 milliseconds to 8 seconds. A Black Friday migration created data inconsistencies. AWS costs exploded from expected $15,000 monthly to $47,000 the first month.

This is what happens when you skip proper modelling and accumulate technical debt.

The Hybrid Approach: Using the Right Tool

Modern consensus has emerged around a polyglot data modelling strategy: use multiple modelling techniques appropriately.

Data Vault or normalised models in integration layers (Silver) provide auditability and flexibility for source system changes
Dimensional models in presentation layers (Gold) provide query performance and business user accessibility
Raw data in Bronze layers enables exploratory analysis

This approach uses the right model for the right use case rather than forcing a single methodology everywhere.

As Margy Ross, co-author with Ralph Kimball and president of DecisionWorks Consulting with 35+ years teaching dimensional modelling to over 10,000 students, addressed directly in 2017:

“The short answer is ‘yes.’ The need to focus on business process measurement events, plus grain, dimensions and facts, is as important as ever. Dimensional modelling has helped countless organisations across every industry make better business decisions which should be the true measure of DW/BI success. While it’s fun to try something new, why dismiss a proven, valuable technique that has provided positive return on investment?”

What Actually Works in 2025

The organisations thriving in modern data environments aren’t those that abandoned modelling for raw data lakes. They’re the ones that adapted dimensional modelling principles to new platforms, combining proven analytical design patterns with modern engineering practices.

Uber’s 100+ petabyte dimensional data lake, Netflix’s unified data architecture, and Spotify’s 500 billion daily events all demonstrate dimensional modelling scales to modern big data volumes.

For teams building modern data platforms, the question isn’t whether to use dimensional modelling—it’s how to implement Kimball principles with tools like dbt, cloud warehouses like Snowflake and Databricks, and lakehouse architectures.

Start with business process identification and careful grain declaration. Build conformed dimensions that enable integration across subject areas. Implement fact tables that capture measurements at atomic grain. Use modern tools like dbt for modular, testable transformations. Leverage cloud platform features for performance and scale. Test rigorously and document thoroughly.

The methodology Ralph Kimball introduced nearly three decades ago continues delivering value because it addresses fundamental challenges in organising data for analytics—challenges that persist regardless of underlying technology.

The evidence is overwhelming. The ROI is measurable. The alternatives are expensive.

Dimensional modelling isn’t dead. It’s just getting started.

References

Analytics8. “Data Modelling in the Modern Data Stack.” Analytics8 Blog. https://www.analytics8.com/blog/data-modeling-in-the-modern-data-stack/
Gartner Research. “The State of Data Quality 2024.” Gartner.
DBSync. “The Cost of Poor Data Quality.” DBSync Research.
McKinsey & Company. “Big Data: The Next Frontier for Innovation, Competition, and Productivity.” McKinsey Global Institute.
Uber Engineering. “Building Uber’s Data Lake.” Uber Engineering Blog.
GeeksforGeeks. “Dimensional Modelling in Data Warehouse.” GeeksforGeeks.
Data-Sleek. “The Four-Step Dimensional Design Process.” Data-Sleek Blog.
McKinsey & Company. “Analytics Comes of Age.” McKinsey Research.

Big Data on Ghost in the data