Use a DAX measure when the result should respond to slicers, visual rows, and filter context. Use a calculated column when you need a stored value for every model row—especially for categories, sort keys, grouping, relationships, axes, or slicers.
The same-looking formula can behave differently because measures run on demand in filter context, while calculated columns run during refresh in row context and store their results.
The decision table
| Question | Measure | Calculated column |
|---|---|---|
| Recalculates when a slicer changes | Yes | No |
| Evaluated during data refresh | No | Yes |
| Result stored in the model | No | Yes |
| Has a row context by default | No | Yes |
| Can be used as a visual value | Yes | Can be summarized |
| Can be placed directly on an axis or slicer | No | Yes |
| Increases model size through stored values | Not like a column | Yes |
Microsoft’s calculation-options guide distinguishes them the same way: calculated columns are refresh-time, stored, row-context calculations; measures are calculated as required and respond to report selections.
Use a measure for dynamic business results
Measures are the default choice for aggregations:
Total Sales =
SUM ( Sales[Sales Amount] )Put [Total Sales] in a card and it returns sales under the card’s current filter context. Put it beside Product Category and it recalculates for each category. Change a Date slicer and it recalculates again.
Common measure use cases include:
- sums, averages, and distinct counts;
- ratios and percentages;
- year-to-date and previous-year comparisons;
- rankings;
- conditional KPIs;
- dynamic titles or labels; and
- calculations that must change with report interaction.
The result is not stored once per fact row. DAX evaluates it when a query needs it.
Use a calculated column for a row-level attribute
A calculated column extends a table:
Sales[Line Amount] =
Sales[Quantity] * Sales[Unit Price]It evaluates for every Sales row during refresh and stores the result in the model. You can then use Sales[Line Amount] in filters or aggregate it in a measure:
Total Line Amount =
SUM ( Sales[Line Amount] )Other good column use cases include:
Product[Price Band] =
SWITCH (
TRUE (),
Product[List Price] < 50, "Low",
Product[List Price] < 200, "Medium",
"High"
)Product[Price Band] can be placed on a slicer or axis because it exists as a model column.
Calculated columns are also useful for:
- sort-by columns;
- stable row classifications;
- concatenated business keys;
- relationship keys when source-side modeling is unavailable; and
- attributes needed by row-level security designs.
Prefer doing stable transformations in the source or Power Query when practical. A DAX calculated column is one option, not the only place to shape data.
Why a measure changes and a column does not
A measure sees filter context:
Margin Percent =
DIVIDE ( [Gross Profit], [Total Sales] )It can return one percentage for 2025, another for 2026, and another for each category.
A calculated column sees its current model row at refresh:
Sales[Row Margin Percent] =
DIVIDE (
Sales[Sales Amount] - Sales[Cost Amount],
Sales[Sales Amount]
)That value belongs to the stored transaction row. Selecting a report year later does not recalculate the row’s original margin.
Both calculations can be valid, but they answer different questions:
- Measure: What is margin percentage for the currently selected group of rows?
- Column: What was margin percentage on this individual stored row?
The measure should usually divide aggregate profit by aggregate sales. Averaging stored row percentages can weight small and large transactions equally and produce a different result.
The most common mistake: storing a total on every row
This calculated column often surprises beginners:
Sales[Model Total] =
SUM ( Sales[Sales Amount] )SUM aggregates the column, and the calculated column’s row context does not automatically filter that aggregation to the current row. The same total can be stored repeatedly.
If the requirement is a report total that responds to filters, use:
Total Sales =
SUM ( Sales[Sales Amount] )as a measure.
If you find a repeated result in an existing report, use the same-value-on-every-row checklist to separate calculated-column behavior from relationship and filter-removal problems.
When both are useful
A robust model often uses both layers.
First create a stable row attribute:
Sales[Line Amount] =
Sales[Quantity] * Sales[Unit Price]Then aggregate it dynamically:
Total Line Amount =
SUM ( Sales[Line Amount] )The column defines the row-level business rule. The measure defines how the report aggregates it under current filters.
However, you may not need the stored column:
Total Line Amount =
SUMX (
Sales,
Sales[Quantity] * Sales[Unit Price]
)This measure evaluates the expression across visible Sales rows at query time. The right choice depends on reuse, model size, source design, and performance—not only formula length.
The SUM versus SUMX guide explains how iterator grain affects totals.
Model-size considerations
A calculated column adds one stored value per row. In a large fact table, a high-cardinality column can materially increase model size.
Examples of high-cardinality values include:
- unique text assembled from multiple fields;
- transaction-level decimals with many distinct values; and
- timestamps or identifiers.
Measures do not create a stored value for each fact row, but complex measures can increase query work. Avoid the false rule that “measures are always fast” or “columns are always bad.” Measure both refresh and query behavior on the real model.
As a default:
- shape stable data as early as practical;
- keep the star schema clean;
- use columns for reusable attributes;
- use measures for report calculations; and
- profile only after the business result is correct.
A six-question decision test
Choose a measure if:
- Should the result change when a slicer changes?
- Is it an aggregate, ratio, ranking, or time comparison?
- Is it used as a value rather than a grouping field?
Choose a column if:
- Do you need one result for every stored row?
- Must users place it on an axis, row, column, or slicer?
- Is it a stable category, sort key, or relationship attribute?
If both sets are true, you may need a column that defines a row attribute and a measure that aggregates it.
Frequently asked questions
Can a measure be used in a slicer?
A model measure cannot be placed directly in a standard slicer as a categorical field. Use a column, field parameter, or a disconnected parameter table, then let a measure respond to that selection.
Are calculated columns static?
They recalculate when the model refreshes, not when a report user clicks a slicer. “Static” means static between refreshes with respect to report interaction.
Should line amount be a column or measure?
It can be either. Use a source or calculated column when the row-level value is reused as an attribute or by many calculations. Use SUMX in a measure when you only need the dynamic aggregate and want to avoid storing another fact column. Test the actual model.
Where can I practice choosing between them?
Work through a DAX Solver challenge. Before writing DAX, state whether the answer belongs to a model row or the current report filter context.
