A calculated column and a measure in Power BI both use DAX, but they serve different purposes and are evaluated at different stages of data processing.
A calculated column is added directly to a table, and its value is calculated row by row. It becomes part of the data model, meaning the values are stored in memory for each row. For example, if I have a Sales table with columns like Quantity and UnitPrice, I can create a calculated column called TotalAmount using this DAX expression:
TotalAmount = Sales[Quantity] * Sales[UnitPrice]
This column physically exists in the model, and each row now has a total amount value. I’ve used calculated columns when I needed to categorize data — for example, creating a column that labels customers as “High Value” or “Low Value” based on their total purchase amount, which could then be used as a slicer in the report.
A measure, on the other hand, is a dynamic calculation that’s evaluated at query time, based on the filters applied in the report. It’s not stored in the data model; instead, it’s computed on the fly. For example, a measure for total sales could look like this:
Total Sales = SUM(Sales[TotalAmount])
When the user filters by region, year, or product, this measure recalculates instantly according to that context. Measures are lightweight and more efficient for aggregations and performance compared to calculated columns.
In one of my Power BI projects, I initially created several calculated columns for revenue and profit calculations. However, I noticed that the report started lagging because the model size increased significantly. Later, I replaced most of them with measures, which improved performance drastically since measures don’t occupy additional memory.
The main challenge I’ve faced was understanding when to use each. Calculated columns are necessary when you need row-level data, like classifications or relationships, but for summaries, KPIs, or aggregations, measures are the right choice.
A limitation of calculated columns is that they increase model size and slow down refresh times. As an alternative, I sometimes pre-calculate such fields in Power Query or in the database itself before loading into Power BI, which helps balance performance and flexibility.