⚡️🗒️Power BI: DAX Calculations [Notes]🆕

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 28-Oct-2026

[feature] DAX Calculations

• {concept} calculated table 
• {def} table created by users using DAX [3]
• stored in the data model [3]
• materialized when the model is refreshed [3]
• becomes a regular table that can participate in relationships, filtering, and reporting [3]
•  unlike a visual calculation or a measure [3]
• enables adding new tables based on data loaded into the model [3]
• instead of querying and loading values into new table’s columns from a data source [3] 
• via a DAX formula that defines the table’s values [3]
• {characteristic} locked after loading
• after the table is loaded or refreshed, its results are locked in and cannot be changed until the table is refreshed [3]
• the results are pre-computed and aren’t dynamically determined [3]
• relatively easy to understand [3]
• because the DAX statement can be inspected and the results can be predicted [3]
• the same statement always returns the same result for the same parameters until the table is refreshed [3]
• {concept} calculated column
• {def} a column created using a DAX formula
• behaves like any other column in a table [3]
• it can be used to define relationships [3]
• {characteristic} calculated row by row 
• can be based on 
• simple formulas (e.g. mathematical operations like addition)
• complex formulas (e.g. combinations of functions) 
• {characteristic} stored in the data model
• ⇒ increases the size of the model [4]
• {characteristic} calculated during refresh 
• calculated when the table is first loaded or refreshed [3]
• can be used in rows, columns, filters, or values of a matrix or any other report [3]
• {exception}[DirectQuery|composite models] computed during the execution of a query [2]
• they do not use RAM, but they are also potentially slower [2]
• they are not evaluated and stored ahead of any query [2] 
• {characteristic}static
• its results cannot be changed until the table is refreshed again [3]
• {characteristic} can be resource-intensive
• especially for large datasets [4] 
• {recommendation} should be used judiciously [4]
• {characteristic} can be used in slicers and filters
•  help create categories users can interact with
• {characteristic) can be used for sorting 
• improves report usability
• {characteristic} support hierarchies and grouping
•  helps organize data into business-friendly groups.
• context transition applies as well [3]
• where a row context is present, and whenever a function is used that iterates over multiple values (aka iterators) [3]
• e.g. SUMX 
• always executed in a row context [2]
• it's possible to create a row context programmatically [2]
• {scenario} placing calculated results in a slicer [2]
• {poor practice} define calculated columns to compute formulas on a row-by-row basis and then aggregate the values [2]
• moving the computation time at data refresh can benefit the overall user experience [2]
• many such scenarios can be successfully solved using iterators instead of creating calculated columns [2]
• categorize text or numbers, especially for filter criteria [2]
• {concept} measure
• {def} a DAX calculation that is evaluated at query time based on the current filter context and returns a result based on the current filter context
• works on sets of rows, producing aggregates of values [2]
• requires aggregators [2]
• computed over multiple lines at once [2]
• does not compute its value on a row-by-row basis [2]
• work on aggregated data [2] 
• reusable
• can reference other measures 
• {characteristic} calculated only when needed
• its output is determined not only by its definition but also by the filter context in which it's executed [3]
•  the same definition can have a different meaning based on the filter context [3]
•  the same measure returns different results depending on
• slicers
• filters 
• visual selections
• row/column groups 
• {characteristic} depends on filter context
•  evaluated within that filter context and often summarizes multiple rows [3]
• {characteristic} consumes little storage/memory
•  only the formula definition, not the results 
• {characteristic} typically used in visuals
•  it can be used by other measures, visual-level/page-level/report-level filters
• used to filter what is displayed
•  it can be used for 
• conditional formatting
• dynamic titles
• dynamic tooltips 
• dynamic format strings
• calculations groups 
• visual calculations 
• {characteristic} must be defined in a table
• a dummy table can be defined for managing (all) measures
• can be moved in between tables
• ⇐ a table is merely a container where the measure is organized without affecting its behavior [2]
• {characteristic} cant be used in relationships
• {characteristic} can't be used direct in slicer fields 
• {type} explicit measure
• created explicitly via the UI 
• can be created programmatically
• via Tabular Editor, TMDL, TOM, XMLA Endpoint, Fabric/PBI, CI/CD
•  
• {type} implicit measure
• created (automatically) when a column is added in the values area of a visual [2]
• not always available
• they do not work when calculation groups are present in the model or when they are disabled in the Tabular model [2]
• {downside} do not guarantee full control over the calculation.
• {benefit} smaller semantic models and lower memory usage
•  store only the DAX formula and metadata, not a value for every row
• {benefit} one measures supports multiple scenarios
• automatically respond to slicers, filters, page/report filters, user selection 
• {benefit} best performance
• faster refreshes, smaller model size, better availability 
• {benefit} reusability 
•  less code duplication, easier maintenance, consistent business logic
• {benefit} support advanced analytics solutions
• time intelligence, running totals, ranking, comparisons, etc. 
• {benefit} centralize business logic
• SSoT/consistent logic across reports 
• {benefit} support modern Power BI features
• tooltips, conditional formatting, dynamic titles, visual calculations, calculations groups, KPIs, etc.
• {recommendation} always define an explicit measure instead of using implicit measures [2]
• allows to modify the global behavior of the calculation without breaking existing reports [2]
• {recommendation} consider creating measures instead of calculated models
• measures are preferred whenever a calculation can be express both ways [2]
• {recommendation} limit the use of calculated columns to the few cases where they are strictly needed [2]
• increase model size, increase refresh time, consume RAM 
• {recommendation} consider moving the calculation to the data preparation stage [2]
• data should be transformed as far upstream as possible and as far downstream as necessary [2]
• {recommendation} use DAX Studio early
•  it allows to inspect the query plan, view filter context, analyze storage engine vs formula engine activity, understand why one measure is faster than another, etc. [2]
• {recommendation} break complex measures into layers [2]
• allows to validate each step independently
• 
  

References:

[1] Greg Deckler & Brett Powell (2024) "Microsoft Power BI Cookbook: Convert raw data into business insights with updated techniques, use cases, and best practices" 3rd Ed.

[2] Alberto Ferrari & Marco Russo (2025) The Definitive Guide to DAX: Mastering the semantic model expression language for Microsoft Power BI, Fabric and Excel

[3] Jeroen ter Heerdt et al (2026) "Microsoft Power BI Visual Calculations: Simplifying DAX"
[4] Cooper Dunn (2025) Microsoft DP-600 Exam Practice Tests: 500 Questions for Implementing Analytics Solutions Using Microsoft Fabric

Acronyms:
CI/CD - Continuous Integration/Continuous Development  
DAX - Data Analysis eXpressions
KPI - Key Performance Indicator
RAM - Random Access Memory
SSoT - Single Source of Truth
TMDL - Tabular Model Definition Language
TOM - Tabular Object Model
XMLA - XML for Analysis