MIP Logo

Measures Vs. Calculated Columns In Power BI

This post was originally published on The Data School blog between 2018 and July 2025, before our program was renamed to MIP’s Analytics Career Accelerator. References throughout this article to “The Data School” or “DS” all refer to what is now MIP’s Analytics Career Accelerator. The program, its people, and its commitment to launching outstanding analytics careers remain the same – just under a new name.

If you are having trouble viewing this article, please report it here

In Power BI, understanding when to use a measure and when to create a new column can impact performance, flexibility, and how data is displayed.

Here’s a detail of the differences, with their advantages, disadvantages, and guidance on usage.

Definition and Calculation:

Calculated Column: Computed in Power Query or DAX, a calculated column is essentially a new field created by applying a formula to each row of a table, much like adding a new column in Excel. These are calculated during data load and stored in the model.

Measure: Measures are aggregations or calculations (like sum and average) created with DAX that operate at the visualization level rather than row-by-row. Measures are computed dynamically based on the filter context of the report.

Storage and Performance:

Calculated Column: Stored in memory within the data model, calculated columns can increase the model’s size, which can impact performance negatively, especially with large datasets.

Measure: Measures don’t add to the data model’s size, as they are calculated only when referenced in a visual, making them more memory-efficient.

 

Aspect Calculated Column Measure
Advantages – Available in the data model for filtering, sorting, and grouping.
– Useful when needing to slice data directly in visuals.
– Memory efficient as it’s not stored in the model.
– Allows dynamic calculations based on user interaction (filter context).
Disadvantages – Increases data model size, potentially slowing download and refresh times.
– Calculated during data load, so cannot respond to real-time changes in filter context.
– Not usable in row-level filtering or direct sorting.
– Can slow down the report if the measure is complex and used extensively in visuals.
Best Use Cases – Static calculations that don’t depend on filter context.
– If you need a new column that users will use to slice or filter data in visuals.
– Dynamic calculations that should respond to user actions and filter context.
– Use when calculations are aggregations or contextual, e.g., SUM, AVERAGE.

 

Speed of Process:

Calculated Columns: Slower during data load and refresh due to being pre-calculated and stored.

Measures: Calculated on the fly, potentially affecting report rendering speed but generally faster at initial data load since they are computed only when used in a visual.

When to Use Calculated Columns and Measures:

Use a Calculated Column When:

  • You need to create static data that won’t change with filters, such as calculated IDs and categories.
  • You want to use the column as a slicer or for sorting and grouping in the visuals.
  • You need to reference this column in multiple calculations or need to perform row-by-row operations, which are better suited to columns.

And, Use a Measure When:

  • You need dynamic calculations that will adjust based on user-selected filters, such as total sales by region, monthly averages, or year-over-year growth rates.
  • You want calculations to respond to slicers and filters dynamically within visualizations.
  • You need efficient memory management, especially for larger datasets, as measures are only calculated at runtime and don’t increase data model size.

Conclusion:

In general, if the calculation doesn’t need to change with context and should appear as part of the model itself (like a new field), use a calculated column. For all other scenarios involving aggregations, dynamic calculations, or memory efficiency, measures are often the better choice.

Share this post