What each one actually does
A measure has no stored result. Power BI computes it on the fly every time you change a slicer, a page filter, or a row in a visual. That is why Total Sales = SUM(Sales[Amount]) can read 1,245,300 on a full view and 318,940 after you click West. The same formula adapts to whatever context the viewer selects.
A calculated column is different. It is evaluated row by row when you load or refresh the model, and the result is written to disk. If you add Sales[Quarter] to the Sales table, every one of the 42,000 rows gets a Q1, Q2, Q3, or Q4 label that never changes unless you refresh. Use it when another column, a slicer, or a relationship needs that value as a fixed attribute.
Create your first measure
In Report view, right-click the Sales table in the Fields pane and choose New measure. Do not click New column, because that creates a calculated column instead of a measure.
Type Total Sales = SUM(Sales[Amount]). The Sales[Amount] syntax means the Amount column inside the Sales table. Power BI underlines valid column references as you type.
Drag Total Sales onto a card visual. With no filters it reads 1,245,300, which is the sum of every Amount value across all 42,000 rows in the Sales table.
Drag the Region column to a slicer and select West. The same measure recalculates to 318,940 because the filter context now limits the rows to West before the SUM runs.
When a calculated column earns its place
When you need a permanent category, add Sales[IsLarge] = IF(Sales[Amount] > 5000, 'Yes', 'No'). Each row is tagged at refresh time and you can slice or color it like any other column.
If Region shows North before East alphabetically but you want a custom order, add a numeric Sales[RegionSort] column and sort the Region column by it in the modeling tab.
In a Products table, add Products[FullLabel] = Products[Category] & ' - ' & Products[Name]. The combined text lives in the model so every visual can use it without a measure.
I recommend starting every new calculation as a measure, then switching to a calculated column only when a visual, relationship, or slicer actually demands a stored value. Measures keep the model lean.
The rule I use to decide
Ask one question: does the answer depend on what the viewer clicked? If yes, it is a measure. Total sales, average order value, and year-over-year growth all shift with the filter context, so they belong in measures. If the value is true for a row no matter what, such as a customer's signup month or a product's weight, store it as a calculated column during load.
A common mistake is building fifteen calculated columns for things that should be measures. Each column eats memory for all 42,000 rows. Push that math into measures and your .pbix file shrinks and refreshes faster.
Mistakes that break reports
This will break if you try to write Total Sales = SUM(Sales[Amount]) inside a calculated column. A column cannot see the filter context, so the number is wrong and cannot respond to slicers.
DAX needs Sales[Amount], not just Amount. Leaving off the table name throws a column-not-found error the moment two tables share a similar column name.
Never name a measure the same as a column, such as Amount for both. You will confuse yourself six weeks later and Power BI will resolve the wrong object in some formulas.
If Amount was imported as text, SUM returns blank. In Power Query set the column type to Decimal Number before you write any measure that totals it.
Worked example: discount impact
Suppose the Sales table holds Amount, DiscountPct, and Region for 42,000 orders. You want net revenue after discount. Create Net Sales = SUMX(Sales, Sales[Amount] * (1 - Sales[DiscountPct])). On the full table this returns 1,098,220, about 12% below the 1,245,300 gross total. Slice to East and it reads 402,110. The measure applies the per-row discount inside SUMX, then sums the results, which a plain SUM of a precomputed column could not do dynamically.
If you know Excel, here is the shift
Excel people reach for SUMIFS to total by criteria. In Power BI the equivalent is a measure, and you stop writing the criteria inside the formula. Instead you drop Region on a slicer and the measure reacts. Our deep dive on SUMIFS and COUNTIFS shows the Excel pattern, and DAX replaces the criteria arguments with live filter context.
Where Excel stores a helper column for every derived value, Power BI prefers measures so the engine only computes what a page actually displays. That difference is the reason a 2 GB Excel workbook often becomes a 60 MB Power BI model.
Quick checks before you publish
Before you share a report, confirm two things about every measure. First, check the storage mode by clicking the measure and reading its formula; a measure shows no data icon in the Fields pane, while a calculated column shows a column icon. Mixing them up is the fastest way to ship a number that will not respond to a slicer.
Second, validate the grand total against a number you trust. If finance says full-year sales are 1,245,300, your Total Sales measure should match it with no filters applied. If it reads higher, you probably double-counted because a relationship is many-to-many; if it reads lower, a filter is stuck on from a previous edit that you forgot to clear.
Drop Total Sales on a card, note 1,245,300, then click West on a Region slicer and confirm 318,940. The change proves the measure is context-aware and not a frozen column copied from a table.
If you added Sales[Quarter], sort the table and confirm every January row shows Q1. A wrong formula here is silent because the column still looks populated and you only notice the error weeks later.
Putting measures on a real dashboard
A measure is only useful when a viewer can slice it. On a sales dashboard, place Total Sales on a card, a bar chart of Total Sales by Region beside it, and a slicer on Region and Month. The same measure feeds all three visuals, so the card, the bars, and the filtered table always agree. This is why measures beat calculated columns for anything the viewer will explore.
When a stakeholder asks a new question, you rarely rebuild the page. You write one more measure, drag it on, and the existing slicers apply automatically. A calculated column would force you to rebuild relationships or add a new field to every visual by hand.
Drag Total Sales to a card. With no filter it shows 1,245,300, giving the viewer the headline number before they touch anything on the page.
Drag Region to a slicer and format it as a dropdown. Selecting East instantly recalculates every measure on the page to 402,110 of regional sales without a single formula change.
I recommend naming measures with a clear prefix like Total or Avg so they sort together in the Fields pane. When a model grows past thirty measures, naming discipline saves you minutes on every edit and stops duplicate names.
Why measures keep the model fast
Calculated columns store a value for every row, so a 42,000-row Sales table with ten calculated columns holds 420,000 extra stored values that the engine must load and compress. Measures compute only what a page displays, so they add almost no storage and rarely slow a refresh. On a large model this difference is the gap between a report that opens in two seconds and one that times out.
The trade-off is that measures compute on the fly, so an extremely complex measure over millions of rows can lag. In practice, a clean star schema and a few well-written measures outperform a column-heavy model every time. Save calculated columns for the rare case where a visual or relationship truly needs a stored field.
When a calculated column is the right call
There are legitimate uses for calculated columns that you should not feel guilty about. Any attribute that labels a row permanently, such as a customer's first purchase quarter or a product's weight class, belongs in a column because relationships and slicers consume it as a fixed field. The test is repeatable: if the value means the same thing regardless of what the viewer clicked, store it.
A second valid case is sorting. Power BI cannot sort a text column by itself meaningfully, so you add a numeric SortOrder column and tell the model to sort the label by it. That numeric column is a calculated column, and it is the correct tool for the job rather than a measure.
Add Sales[RegionSort] = SWITCH(Sales[Region], 'North',1,'East',2,'West',3,'South',4) then set Region to sort by RegionSort in the column tools tab so the bars appear in your preferred order.
Drop Region on an axis and confirm North appears first. Without the helper column, alphabetical order would put East before North and quietly confuse every reader of the chart.
Common beginner questions
The question that trips up most newcomers is whether a calculation should live as a measure or a column when both seem to work on a small sample. Test it by slicing: if the number changes when you click a Region, it must be a measure. A calculated column shows the same value on every row of a visual because it has no filter context to react to.
The second frequent confusion is why a measure returns blank on a card but works in a table. Usually the card sits on a page with a filter you forgot, or the column type is text. Check the Filters pane for a stuck Region, and confirm Amount is Decimal Number in Power Query before you blame the formula.
Place the measure on a table by Region. If East shows 402,110 but the card shows blank, a page-level filter is hiding the card's context; clear it in the Filters pane.
Open Power Query and check the Amount column type. A text Amount makes SUM return blank, and switching it to Decimal Number fixes the measure with no formula change.
A one-line recap
If you remember one thing, remember the test: a number that must change with the slicer is a measure, and a value that is true for a row no matter what is a calculated column. Total Sales = SUM(Sales[Amount]) is a measure because West drops it to 318,940, while Sales[Quarter] is a column because it is fixed per row at refresh time.
Build the habit of starting every calculation as a measure, then promote it to a column only with a concrete reason such as sorting or a relationship key. Your models stay smaller, your refreshes stay fast, and your totals stay consistent across every page of the report.
Next steps
Practice this split on your own data: build three measures (a total, an average, a ratio) and resist the urge to add calculated columns. When you are comfortable, learn CALCULATE to override the filter context on purpose. The data modeling guide explains how relationships feed those measures, and the PL-300 certification guide maps these skills to the exam.
If you are studying for a credential, the PL-300 guide lists exactly which DAX functions appear most often. Pair it with the Power BI vs Tableau comparison if you have not yet picked your main tool.
