The Hidden Economy of Power BI: Why Good Models Favor Questions Over Columns

Jul 07, 2026

10 min read

2 views

87%

The real question behind every model

What if the most important decision in Power BI is not what calculation to write, but what kind of information should exist at all?

That question sounds almost philosophical, yet it sits at the center of practical modeling. Every dataset tempts us to add more columns, more derived fields, more convenience. A total here, a category there, a flag for this, a ranking for that. It feels efficient because the answer is right in the table, ready to be queried. But convenience has a hidden cost: each added column hardens the model, inflates the file, and quietly turns a flexible analytical system into a bloated spreadsheet in disguise.

The deeper tension is this: should a model store answers, or should it remain capable of producing answers on demand?

That tension is not just about performance. It is about the shape of thinking. A good model does not merely hold data. It encodes a philosophy of use, one that separates what must be permanent from what should remain variable, contextual, and alive.

When convenience becomes debt

The instinct to add calculated columns is understandable. If you need a row by row value, a column seems natural. If every transaction needs a category, a status, or a computed margin, then putting that result in the table feels clean. It is visible, inspectable, and easy to reason about.

But visibility can be deceptive. A calculated column is not free. It is materialized in the file, meaning it occupies space for every row, whether anyone ever looks at it or not. If your table has 1,000 rows, the new column contains 1,000 stored values. If you add five such columns across a large model, you are not just adding convenience. You are increasing file size, slowing refresh, and narrowing the ceiling of what your model can hold before it becomes unwieldy.

Think of it like keeping a printed copy of every possible answer in a library, even though most readers will only ever need a few of them at a time. The library becomes easier to browse in one sense, but far more expensive to maintain. Eventually, the shelves fill up, the building strains, and the real purpose of the library, fast access to knowledge, gets buried under storage.

This is why the distinction between row level storage and on demand computation matters so much. A calculated column says, “Save this result forever.” A measure says, “Compute this only when someone asks, and compute it in context.” Those are not merely technical alternatives. They are two different theories of how intelligence should live inside a model.

A bloated model is often a sign that too many questions were turned into permanent facts.

The most common modeling mistake is to confuse analytical convenience with structural necessity. We add columns because it makes the report easier today, then inherit a slower, heavier, less adaptable system tomorrow. The short term gain is undeniable. The long term cost is often invisible until it is too late.

Simple tables are not simpler by accident

There is a reason well designed models favor simple, readable tables and strong relationships over dense monolithic structures. Simplicity in data modeling is not aesthetic minimalism. It is a form of cognitive compression.

A simple table structure is easier to navigate because each table has a clear job. One table holds transactions. Another holds products. Another holds dates. Relationships connect them in a way that mirrors the business, not the clutter of every report requirement. This separation does two things at once. It makes the model easier for humans to understand, and it makes the system easier for the engine to work with.

This is where table design and calculation design meet. If tables are well organized, then many calculations can remain measures instead of becoming stored columns. A clean relationship structure gives the measure the context it needs to answer different questions without duplicating data. In other words, good tables reduce the need for stored answers.

Imagine a restaurant kitchen. If every plate comes pre assembled with every possible sauce, garnish, and side dish, the kitchen is full of redundant work. But if ingredients are organized well, then the chef can assemble exactly what each order requires. The pantry is simpler, the workflow is faster, and the final plate is more adaptable to the customer. A Power BI model works much the same way. The point is not to prebuild every possible report. The point is to store the ingredients in a structure that can serve many queries cleanly.

There is also a subtle relational benefit here. When tables are merged or appended thoughtfully, they become simpler to navigate and less likely to create confusion. But the goal is not to merge everything into one massive table. It is to reduce unnecessary fragmentation while preserving meaningful structure. Good modeling is not about minimizing table count at all costs. It is about making each table earn its existence.

That shifts the question from “Can I calculate this now?” to “Where does this fact belong, and should it belong there permanently?”

Measures are not just faster, they are more honest

The most powerful idea in this entire space is that measures behave like questions.

A measure is computed on demand. It waits until the user applies filters, slices by year, compares employees, or drills into product. Then it returns the result appropriate to that context. This is not merely a performance feature, although it certainly helps with file size and refresh time. It is an epistemic feature. Measures acknowledge that many business truths are not fixed until you specify the frame around them.

Take total sales. The number is meaningless without context. Total sales for all time, for one year, for one region, for one salesperson, for one product line, all of these are different answers to the same underlying question. A calculated column cannot express that fluidity gracefully because it stores one value per row, detached from the changing shape of analysis. A measure, by contrast, responds to the context the user creates.

This is why measures feel closer to natural reasoning. People do not usually think, “What is the sales value permanently attached to row 843?” They think, “What were sales last quarter in the Northeast for this category?” The business question is inherently contextual. Measures preserve that context instead of flattening it into stored results.

The best analytical systems do not store every answer in advance. They store the conditions under which answers can be discovered.

That is an important reframing. A model is not just a warehouse of facts. It is a machine for producing interpretations. Measures are the mechanism that keeps interpretation alive. They allow a report to remain responsive to the person using it, rather than imposing a single frozen viewpoint on the data.

This also explains why quick measures can be so useful. Even without writing code, you are choosing a design principle: compute when needed, not before. The act of deferring computation is not laziness. It is discipline.

A mental model: facts, formulas, and frames

A useful way to think about modeling is to separate three layers:

Facts: the raw events or entities that should live in tables.
Formulas: the logic used to derive meaning from those facts.
Frames: the filter context that determines which meaning is relevant right now.

Calculated columns belong closest to facts, but they are still formulas frozen into storage. Measures belong to the interaction between formulas and frames. They are not just calculations. They are context aware interpretations.

This distinction explains why some business logic belongs in the source query or Power Query, while some belongs in DAX as a measure. If a value is truly intrinsic to the row, and it will never need to vary by report context, then materializing it upstream may be reasonable. But if the value is an answer to a question, not a property of the row, then storing it too early is a category error.

For example, imagine a table of orders. A column for order date belongs in the fact table because it is part of the event itself. A column for order amount might also belong there because it is a recorded fact. But “total sales by year” is not a row property. It is an aggregation that only exists when viewed through time. Store it as a column and you collapse a relationship into a static number. Define it as a measure and you preserve its dependence on context.

This mental model helps resolve a common confusion: not every useful result should become a column just because it is available. Some results are better understood as answers generated at the moment of inquiry.

Designing for the future user, not the present workaround

Most models are overbuilt for today’s dashboard and underbuilt for tomorrow’s questions.

That is because design often starts with a specific report request. Someone wants a KPI, a trend line, a comparison, and the quickest path is to add the columns needed to make that one report work. The model gets optimized for the immediate deliverable. Yet the real value of analytics is not one report. It is the ability to keep asking better questions without rebuilding the entire foundation.

A measure centric model supports that future more gracefully than a column centric one. Because measures respond to filters, they can adapt to new slices of the data without requiring new storage. Because tables are kept simple and relationships meaningful, new questions can often be expressed by rearranging the same model rather than rewriting it. This is what makes a model durable: not that it answers one question perfectly, but that it can answer many questions without becoming heavier every time.

Consider the difference between owning a custom tool for each task and owning a modular toolkit. The first feels satisfying when the task is known. The second becomes invaluable when the task changes. Analytic models need to behave like toolkits, not trophies. The more you store as permanent columns, the more each new question demands a new artifact. The more you rely on measures, the more the model becomes a reusable reasoning system.

This is where simplicity in table design and on demand calculation reinforce each other. A clean relational structure lowers the number of stored transformations you need. A measure based approach prevents that structure from being polluted by every temporary business request. Together, they produce a model that is both legible and elastic.

Key Takeaways

Treat calculated columns as storage, not convenience. If the value does not need to exist for every row all the time, it may not belong in a column.
Use measures for questions, not properties. If the answer changes with filters, time, or user selection, it should probably be calculated on demand.
Keep tables conceptually simple. Each table should have a clear purpose, and relationships should carry meaning rather than compensate for poor structure.
Push truly row specific logic upstream when possible. If a calculation is intrinsic to the data and stable, consider the source query or Power Query before DAX.
Design for future questions, not just current reports. The best model is one that remains flexible as analytical needs evolve.

The deeper discipline: preserving optionality

The best models preserve optionality. They do not rush to make every possible answer permanent. They keep the structure lean enough to support new interpretations, new filters, and new business questions without forcing a redesign each time.

That is why this topic is bigger than Power BI. It is a lesson in how to think about any system that processes information. There is always a temptation to convert uncertainty into storage, and inquiry into precomputation. It feels safe. It feels efficient. But the more we harden our interpretations into columns, the less room we leave for context, surprise, and discovery.

A strong model does something subtler and more powerful. It makes the important facts stable, while leaving the meaning of those facts responsive to the situation. It knows what should be recorded once, and what should be evaluated anew every time someone asks.

In that sense, the real hallmark of a good analytical model is not how much it stores. It is how intelligently it resists storing what should remain a question.