It’s the most innocent sounding request in data engineering.
When I first started building star schemas for reporting, I didn’t fully understand why senior engineers were so protective about dimensional design. A column is just a column, right? Add it to the fact table, move on.
Then I experienced the consequences firsthand.
The Seductive Simplicity of “Just One More”
Here’s what typically happens: A business user needs a specific attribute in a report. The fact table already contains the main records, so why not just add that attribute there? It’s faster than creating a proper dimension table. One quick ALTER TABLE statement and you’re done.
Six months later, that fact table has grown from 15 columns to 47. Query performance has degraded from 2 seconds to 45 seconds.
And every new analyst who joins the team asks “Why is this attribute stored in three different places with three different values?”
The Real Cost Isn’t Technical
Poor dimensional modeling doesn’t just slow down queries. It creates:
1. Confusion about source of truth
When descriptive information lives in the fact table AND a dimension table AND gets calculated differently in various reports, nobody knows which version is correct.
2. Exponential maintenance complexity
Every column added to a fact table creates ripple effects. When business logic changes you’re now updating multiple places instead of one dimension table. That “simple” column becomes a maintenance nightmare multiplied across every pipeline that touches that table.
3. Query performance degradation
Fact tables can contain millions of records. When you’re joining unnecessarily wide fact tables instead of leveraging properly indexed dimension tables, you’re forcing the database to process far more data than needed.
4. Lost flexibility
Want to track historical changes to descriptive attributes? If descriptive data lives in your fact table, you can’t. Proper dimension tables preserve historical values, giving you the ability to report on data as it was at any point in time. Fact table columns only tell you what’s true right now.
One Big Table
In the mid-2010s, as cloud data warehouses exploded in popularity, a new philosophy emerged: “One Big Table” (OBT). Storage was cheap. Columnar databases were fast. Why maintain complex star schemas when you could just denormalise everything into one massive, wide table?
The promise was irresistible: better performance, simpler queries, no complicated joins for business users.
Organisations rushed to adopt the approach. Data teams celebrated eliminating “unnecessary” dimension tables. Analysts loved writing simpler SQL.
Then reality hit.
As data sources multiplied, these Wide Tables became unmaintainable. Every schema change required rebuilding the entire table. Historical tracking became impossible and you could only see the current state. When business logic changed, there was no single place to update definitions. Teams found themselves with multiple competing versions of the same “One Big Table,” each slightly different, none authoritative.
The initial performance gains evaporated under the weight of operational complexity. What started as an optimisation became a maintenance nightmare that cost organisations millions in refactoring projects.
The lesson? Faster queries mean nothing if your data warehouse becomes impossible to maintain.
The Real Lesson
Dimensional modeling isn’t just theory. It is what separates data warehouses that scale gracefully from those that collapse under their own complexity.
The senior engineers who push back on “just one more column” aren’t being difficult. They’re protecting you from six months of technical debt.
Every column you add to a fact table is a small decision. But small decisions compound.
Star schema design isn’t about perfection, it’s about making those small decisions in a way that keeps your data warehouse flexible, performant, and understandable as it grows.
The question isn’t “Can we add this column to the fact table?”
It’s “Will this decision make our data warehouse easier or harder to work with a year from now?”
Usually, the answer is: create the dimension table.
Cate Bernard
Graduate Data Consultant
