.svg){kind=small}
Measures and calculated columns both use DAX in Power BI, but they solve different problems. A calculated column produces a value for each row and stores that result in the semantic model. A measure calculates a result when it is needed and responds dynamically to the filters and selections in a report.
Choosing the wrong one is a common source of confusing DAX, unnecessarily large models and calculations that do not respond to report filters in the way you expect.
Measures vs calculated columns at a glance
| Calculated column | Measure |
|---|---|
| Calculated row by row | Calculated when the result is needed |
| Stored in the model | Result is not stored as a column |
| Useful for categorisation and row-level attributes | Useful for totals, ratios and dynamic analysis |
| Can be used in slicers, axes and filters | Normally used as a value or visual-level filter |
| Primarily associated with row context | Primarily evaluated in filter context |
| Increases model size | Uses computation when evaluated |
What is a calculated column?
A calculated column adds a new column to a table using a DAX expression.
Power BI evaluates the expression for each row when the model is processed or refreshed and stores the resulting values.
For example, imagine a Sales table contains Quantity and UnitPrice. A calculated column could create a row-level value:
Line Value = Sales[Quantity] * Sales[UnitPrice]
Every row receives its own Line Value.
Calculated columns can then be used like many other model columns. They can appear in slicers, visual axes, rows, columns, filters and relationships when appropriate.
What is a measure?
A measure is a DAX calculation evaluated when Power BI needs the result.
A simple measure might be:
Total Sales = SUM(Sales[SalesAmount])
If you place Total Sales in a card, it calculates the total for the current report context. Put the same measure in a table by Product Category and Power BI recalculates it separately for each category. Select a year in a slicer and the measure recalculates again for that year.
Microsoft's current Power BI guidance explains that measures are calculated as needed and respond to selections made in the report.
The key difference: stored value vs dynamic result
The easiest way to understand the distinction is to ask whether you need a value attached to every row or a result that should change according to report context.
Calculated column: “What category does this individual row belong to?”
Measure: “What is the result for whichever group of rows the report user is currently looking at?”
Example: customer age band
Suppose each customer already has an Age value and you want to classify them into bands such as:
- 18–29
- 30–44
- 45–59
- 60+
If the age band is a stable row-level category that you want to place on an axis or slicer, a calculated column can be appropriate.
Each customer receives one band value that can be used to group other calculations.
Example: total revenue
Total revenue should normally be a measure.
You do not want to store “total revenue” on each sales row because the total depends on context. Users may want total revenue for:
- all years
- 2026 only
- one customer
- one product category
- one region
- a selected combination of several filters
A measure recalculates appropriately for each context.
What is row context?
Row context can be understood as the “current row”.
Calculated columns naturally operate with row context because Power BI evaluates the expression separately for each row in the table.
If the current Sales row contains Quantity = 3 and UnitPrice = £20, the calculated column can multiply those two values for that row and return £60.
Iterator functions such as SUMX can also create row context while evaluating a measure.
What is filter context?
Filter context is the set of filters that determines which data is relevant when a measure is evaluated.
Filter context can come from:
- slicers
- rows and columns in visuals
- report, page and visual filters
- relationships between tables
- DAX functions such as CALCULATE
Understanding filter context is one of the biggest steps in learning DAX properly.
See What Is DAX in Power BI? for a broader introduction.
Why do measures usually make better totals?
Measures are designed for aggregation in a changing report context.
Imagine a Profit Margin calculation:
Profit Margin = DIVIDE([Profit], [Revenue])
A measure can calculate the correct margin at product, customer, month, region or company level because it divides the aggregated Profit and Revenue values for the current context.
A row-level calculated percentage that is later averaged may produce a completely different and potentially misleading result.
Why not create everything as calculated columns?
Calculated columns are easy for Excel users to understand because they feel similar to formulas filled down a worksheet. But using them for every calculation has disadvantages.
Calculated columns:
- consume memory because their values are stored
- increase model size
- do not dynamically recalculate simply because a report filter changes
- can encourage row-level logic where an aggregate measure would be clearer
This does not make calculated columns bad. It means they should be used when a stored row-level attribute is genuinely needed.
Why not create everything as measures?
Measures cannot replace every calculated column.
A measure cannot generally be used as a normal category in a slicer or chart axis because it does not create a stored value for each row in the model.
If you need to classify each product as “High”, “Medium” or “Low” based on a stable row-level attribute and then use that classification to group data, a column may be the appropriate model object.
Calculated columns vs Power Query custom columns
There is another important choice: should a row-level calculation be created in DAX at all?
Power Query custom columns are created during data preparation before data is loaded into the model.
DAX calculated columns are created inside the semantic model after data is loaded and can work with model relationships.
If a value can be calculated reliably during data preparation and does not need DAX-specific model behaviour, creating it upstream in Power Query or the source system can sometimes be more efficient.
The correct choice depends on the logic, data source and model design.
When should you use a calculated column?
A calculated column can be useful when you need:
- a category for a slicer
- a label for a visual axis
- a row-level classification
- a sort-by column
- a key or attribute needed by a relationship
- a value that depends on other columns in the same row
- a value that uses DAX relationships and is genuinely best created in the model
When should you use a measure?
Use a measure when you need:
- totals
- averages
- counts
- distinct counts
- ratios and percentages
- year-to-date values
- comparisons against previous periods
- variance against target
- rolling calculations
- results that respond to report filters
Most analytical calculations displayed as values in Power BI reports should normally be measures.
A practical sales example
Assume a model contains a Sales fact table and Product, Customer and Date dimensions.
Useful calculated columns might include:
- a product grouping that does not exist in the source
- a row-level status classification
- a sort-order number for a custom band
Useful measures might include:
- Total Sales
- Total Cost
- Profit
- Profit Margin
- Distinct Customers
- Average Order Value
- Sales YTD
- Sales vs Previous Year
The dimensions provide the report context, and the measures calculate the answers.
How does star schema affect this decision?
A well-designed star schema often makes the distinction much clearer.
Dimension tables contain descriptive attributes used for grouping and filtering. Fact tables contain events and measurements. Measures aggregate the facts according to filters coming from dimensions.
This separation reduces the temptation to create complicated row-level calculations to compensate for a confusing model.
See Power BI Star Schema Explained.
What happens when a report filter changes?
A stored calculated column does not recalculate its underlying row values because a user selects a slicer. Its values were produced when the model was processed.
A measure is reevaluated in the new filter context. This is why one Total Sales measure can power many different visuals.
Can measures reference other measures?
Yes, and this is an important modelling pattern.
You might create:
Revenue = SUM(Sales[Revenue])
Cost = SUM(Sales[Cost])
Profit = [Revenue] - [Cost]
Profit Margin = DIVIDE([Profit], [Revenue])
Building calculations from reusable base measures makes models easier to understand and maintain.
Can calculated columns reference measures?
There are scenarios where DAX interactions become more advanced, but beginners should avoid treating measures and calculated columns as interchangeable building blocks. Their evaluation contexts and timing are different.
Start by deciding what business result is required and whether it is a row attribute or an analytical aggregation.
What is context transition?
Context transition is an important advanced DAX concept in which row context is transformed into filter context, most notably through CALCULATE.
You do not need to master context transition before writing your first measures, but it becomes important when calculations behave unexpectedly in calculated columns or iterator expressions.
Which uses more memory?
Calculated columns add stored data to the model, so they increase its memory footprint. How much depends on the number of rows and the cardinality and data type of the calculated values.
Measures store the expression rather than a precomputed result for every row. Their results are evaluated as queries run.
Performance is more nuanced than simply saying “measures are faster”. A poorly written measure can be expensive to calculate, while a sensible low-cardinality column may be efficient. The key is using the right modelling technique for the requirement.
Common beginner mistakes
- Creating a calculated column for every total. Dynamic report calculations belong in measures.
- Expecting a calculated column to respond to slicers. Its stored row values do not work that way.
- Trying to use a measure as a normal slicer category. Measures do not create stored row attributes.
- Creating DAX columns for transformations better handled in Power Query.
- Ignoring model relationships. Many DAX problems are really data-model problems.
- Averaging row-level percentages. This can produce incorrect business totals.
- Writing complex DAX before defining the required grain and context.
A simple decision checklist
Ask these questions:
- Do I need a value stored for every row?
- Will the result be used as a category, axis or slicer?
- Should the result change when report filters change?
- Is this fundamentally an aggregation such as a total, ratio or count?
- Could this transformation be completed earlier in Power Query or the source database?
If the answer centres on dynamic aggregation, a measure is usually the better choice. If you genuinely need a row-level model attribute, a calculated column may be appropriate.
Frequently asked questions
Should I use a measure or calculated column for total sales?
Usually a measure. Total sales should respond to filters such as date, product and customer.
Can calculated columns be used in slicers?
Yes. Calculated columns create stored values and can be used for grouping and filtering like other suitable model columns.
Can measures be used in slicers?
Not as ordinary categorical slicer fields. Measures return calculated results rather than stored category values.
Do measures make a Power BI model smaller?
Measures do not store a result for every row, so replacing unnecessary calculated columns with appropriate measures can reduce model size. Overall model size still depends on all imported columns, cardinality and storage design.
Should I calculate a new column in Power Query or DAX?
If the value can be created during data preparation and does not need DAX-specific relationship behaviour, Power Query may be preferable. Use DAX calculated columns when the calculation genuinely belongs in the semantic model.
Are implicit measures the same as explicit measures?
No. Power BI can automatically aggregate numeric columns in visuals, creating implicit calculations. An explicit DAX measure is deliberately defined in the model and can be reused consistently across reports.
Develop your Power BI DAX skills with ExperTrain
ExperTrain's Power BI Desktop Intermediate course introduces calculated columns and measures alongside Power Query and data modelling. The Power BI Desktop Advanced course develops these skills further with more sophisticated DAX and modelling techniques.
If you are just starting, Power BI Desktop Introduction provides the foundation.
You can also explore the Power BI Glossary and read What Is DAX in Power BI?, Power BI Star Schema Explained and Power Query vs Power Pivot.
Further reading
Found this article useful? Add ExperTrain as a Preferred Source on Google to help surface more of our training guides, articles and learning resources.
.png){kind=small}
