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
[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
