Guides

Measures vs Calculated Columns in Power BI (When to Use Which)

By Ravindra Bagale, Power BI & Data Analytics trainer · LinkedIn · Published: 30 September 2026 · Last updated: 30 September 2026

A calculated column stores a DAX result on every row (usually at refresh). A measure calculates on demand using the filters from slicers and visuals. Use measures for totals. Use columns for row-level fields you need to slice or label.

Column  → stored per row @ refresh (row context)
Measure → calculated @ query time (filter context)

What do I need before this guide?

• A .pbix with a Sales-like table (Excel/CSV guide).
• Comfort clicking Report / Data / Model views.
• Course recap: Calculated columns vs measures.

Before and after (look at the tables first)

A column stores TaxCol on every row (here 18%). A measure like [Total Sales] still sums Amount under filters — start with measures for KPIs.

Why the difference exists (and why you care)

Power BI must answer two different questions.

1. Row question: “For this order line, what is tax?” → natural for a column.
2. Visual question: “Given the slicers right now, what is total sales?” → natural for a measure.

Why you care:

1. If you store every possible total as a column, the model gets fat.
2. A fat “total column” still will not behave like a slicer-aware KPI.
3. Interviews love one clean sentence: columns store row values; measures calculate under filters.

Tiny Sales table we will reuse:

Calculated column — what it is, why, how, what you see

What it is

A calculated column is a new column on a table. DAX fills a value for each row. Power BI usually stores those values when data refreshes.

Why use a calculated column

1. You need a label or flag on every row (High / Normal).
2. You need a field on a slicer, axis or row (measures cannot be slicer fields).
3. You need tax or a category sitting beside Amount in Data view.

Why you do not use a column for every KPI

1. Totals that must follow slicers belong in measures.
2. Extra numeric columns eat memory on big tables.

How to create one (vertical steps)

1. Select the Sales table in Data or Report view.
2. Table tools → New column (wording varies slightly by version).
3. In the formula bar type:

TaxCol = Sales[Amount] * 0.18

4. Press Enter.
5. Open Data view and look at the new column.

What Power BI does to the rows (tiny example)

1. Row Mumbai Amount 100 → TaxCol = 100 × 0.18 = 18.
2. Row Pune Amount 40 → TaxCol = 40 × 0.18 = 7.2.
3. Those two values are stored on the rows.

What you see on screen

1. Data view shows TaxCol filled for every row.
2. You can put TaxCol on a table visual or even on a slicer later if needed.

Measure — what it is, why, how, what you see

What it is

A measure is a formula that runs when a visual asks for a number. It respects filter context (the filters from slicers, the Filters pane and the visual itself).

Why use a measure

1. Sums, averages and counts that must change when the reader picks Mumbai.
2. Ratios like Total Sales / Orders.
3. Almost every executive KPI card.

Why SUM (not a “total column”) for KPIs

1. Total Sales = SUM ( Sales[Amount] ) re-adds only the rows that survive filters.
2. A column cannot “listen” the same way when used as a card KPI.

How to create one (vertical steps)

1. Select the home table (Sales).
2. Click New measure.
3. Formula bar:

Total Sales = SUM ( Sales[Amount] )

4. Fields pane shows an fx style measure icon.
5. Drop it on a Card.

What Power BI does to the rows (tiny example)

1. No slicer: rows Mumbai 100 + Pune 40 → measure returns 140.
2. City slicer = Mumbai: only the Mumbai row remains → measure returns 100.
3. City slicer = Pune: only Pune remains → measure returns 40.

What you see on screen

1. Card shows 140, then 100 when Mumbai is selected.
2. TaxCol still shows 18 and 7.2 on each row in Data view — that does not replace the measure.

Side-by-side comparison

Common mistakes

1. Creating a calculated column that is only SUM ( Amount ) thinking it is a KPI — that pattern fights you.
2. Building 20 numeric columns “just in case” instead of measures.
3. Expecting a column to “listen” to slicers the way a measure does when used wrongly on cards.
4. Writing measure syntax into a column without understanding row context (errors or wrong results).

Ghabru naka — fix by deleting the bad column and writing a measure.

Worked “profit flag” example

// column — row label you might filter on
ProfitFlag =
IF ( Sales[Amount] >= 100, "High", "Normal" )

What happens to rows:

1. Mumbai 100 → ProfitFlag = High.
2. Pune 40 → ProfitFlag = Normal.

// measure — KPI
High Sales Amount =
CALCULATE (
    SUM ( Sales[Amount] ),
    Sales[ProfitFlag] = "High"
)

Why use CALCULATE here:

1. You want Total Sales, but only for rows flagged High.
2. CALCULATE temporarily adds that filter, then runs the sum.
3. With both cities visible, High Sales Amount = 100 (only Mumbai).

Why both can coexist:

1. The column classifies each row.
2. The measure totals under that classification (and other slicers).
3. Prefer measures for cards.

Storage intuition with numbers

1. 1,000,000 sales rows × 5 calculated numeric columns ≈ lots of stored values.
2. 20 measures ≈ 20 formulas.
3. That is why “measure first for totals” is not ideology — it is hygiene.