SUMX vs CALCULATE in DAX: Which One Is Really Faster? | by Thebitoolbox | Jul, 2026

Press enter or click to view image in full size

For years, Power BI practitioners have repeated a single phrase like a mantra:

“CALCULATE is faster than SUMX.”
“Avoid SUMX because it’s a slow iterator.”

It sounds convincing and intuitive… until you actually put it to the test.

In this article we will review a full set of performance benchmarks comparing SUMX and CALCULATE on simple, medium and complex DAX patterns. To ensure absolute accuracy, results were captured from both Power BI Performance Analyzer and DAX Studio. All tests were repeated several times with the cold cache cleared before execution.

The results were surprising, educational and a reminder of how the DAX engine actually works under the hood.

A Short Disclaimer

This article is based purely on empirical performance numbers, not on theoretical assumptions. One basic truth that became very obvious early in the course of testing is: The performance is not dependent on the keyword SUMX orCALCULATE. It depends on what the measure forces the engine to do in the background.

Now, let’s get to the benchmarks.

🔍 Test 1 — The Basic Row Filter (CALCULATE + FILTER vs. SUMX)

Here, both measures should give exactly the same semantic value. Let’s filter a large sales data set where quantity is greater than 5.

-- Version 1: CALCULATE + FILTER
Sales CALCULATE + FILTER = 
CALCULATE (
SUM ( Sales[SalesValue] ),
FILTER ( Sales, Sales[Quantity] > 5 )
)
-- Version 2: SUMX
Sales SUMX = 
SUMX (
FILTER ( Sales, Sales[Quantity] > 5 ),
Sales[SalesValue]
)

The Benchmarks:

Power BI Performance Analyzer:

• CALCULATE + FILTER: ~7,438 ms
• SUMX: ~293 ms

DAX Studio (Cold Cache):

• CALCULATE + FILTER: ~10,577 ms
• SUMX: ~900 ms

Press enter or click to view image in full size

What went wrong?

And this is the day’s first major plot twist. The CALCULATEversion did disastrously worse. Why?

This is due to a fundamental DAX mechanism : Context Transition.
By wrapping CALCULATEinside a FILTERiterator that scans the full Sales table, we force the engine to convert the row context into a filter context for every single row in that table. This creates a huge architectural bottleneck where the very efficient Storage Engine (SE) cannot do its job. Instead, all the heavy lifting is pushed to the Formula Engine (FE) that evaluates the expression row by row, sequentially.

SUMX is a native iterator, by contrast. It too iterates, but with a lot less overhead in this particular anti-pattern and with a lot more grace in the row-by-row logic.

Lesson learned: Wrapping CALCULATE inside a full-table FILTER destroys its built-in optimizations.

🔍 Test 2 — Removing the FILTER Wrapper (Simple Column Predicate)

Next, let us optimize the CALCULATE measure, by eliminating the explicit FILTERiterator and replacing it with a simple, clean Boolean column expression.

Sales CALCULATE NO FILTER = 
CALCULATE ( 
SUM ( Sales[SalesValue] ), 
Sales[Quantity] > 5 
)

The Benchmarks:

Power BI Performance Analyzer:

• SUMX: ~262 ms
• CALCULATE (No FILTER): ~229 ms

DAX Studio (Cold Cache):

• Both measures leveled out at around ~900 ms.

Press enter or click to view image in full size

“What happened?”

By removing the FILTERfunction we enabled the DAX compiler to rewrite the query in an optimized form internally.

With the explicit row-by-row instruction not being there, the Storage Engine (SE) can now step in and push the predicate filter directly down to the VertiPaq database level. CALCULATEimmediately gets its structural advantages back, and SUMXloses its previous huge lead.

This test shows an important point: CALCULATEis fast by nature only when its filters can be translated into efficient Storage Engine operations.

🔍 Test 3 — Two Conditions (Quantity + Discount)

Now we will add two independent column predicates on two different attribute (Quantity and Discount) to make it a bit more complex.

-- Complex CALCULATE v1
Sales CALCULATE 2 Predicates = 
CALCULATE (
SUM ( Sales[SalesValue] ),
Sales[Quantity] > 5,
Sales[Discount] < 0.1
)
-- Complex SUMX v1
Sales SUMX 2 Predicates = 
SUMX (
FILTER ( 
Sales, 
Sales[Quantity] > 5 && Sales[Discount] < 0.1 
),
Sales[SalesValue]
)

The Benchmarks:

Power BI Performance Analyzer:

• CALCULATE: ~215 ms
• SUMX: ~239 ms

DAX Studio (Cold Cache):

• CALCULATE: ~257 ms
• SUMX: ~267 ms

What happened?

The differences in performance here are essentially noise. Both versions are very similar in speed.

The engine can seamlessly optimize both execution plans because both measures use simple column predicates, contain no RELATEDcross-table functions, and do not wrap CALCULATEinside an external iterator. Both are very SE-friendly, so the physical queries that go to the database are almost the same thing under the hood.

🔍 Test 4 — Adding Cross-Table Logic (RELATED)

What if we add a filter condition that exists in a related dimension table and not in the local fact table? Let’s filter using a specific product category usingRELATED.

-- Complex CALCULATE with RELATED
Sales CALCULATE v2 = 
CALCULATE (
SUM ( Sales[SalesValue] ),
FILTER (
Sales,
Sales[Quantity] > 5 && RELATED ( Products[Category] ) = "Electronics"
)
)

The Benchmarks:

Power BI Performance Analyzer:

• CALCULATE: ~2,673 ms
• SUMX: ~281 ms

DAX Studio (Cold Cache):

• CALCULATE: ~4,153 ms
• SUMX: ~798 ms

What happened?

CALCULATEtakes a huge hit in performance again, while SUMXhas no problem whatsoever.

The RELATEDfunction creates a tight row context dependency by relationships within the FILTERcontext. This pattern in the structure prevents the Storage Engine from optimizing the evaluation of the filter. The execution plan switches back heavily into the Formula Engine (FE), which does not handle multi-table line-by-line lookups well. SUMXis a native iterator designed to scan row-by-row and addresses this specific overhead with far greater structural efficiency.

🔍 Test 5 — The Expensive Row Expression (Multiplication via Iterator)

Finally, let’s test a scenario where we need to do an expensive mathematical calculation at the row level (multiply the local sales value by a unit price located in a related dimension table).

-- CALCULATE Version with internal iterator
Sales CALCULATE Expensive = 
CALCULATE (
SUMX ( Sales, Sales[SalesValue] * RELATED ( Products[UnitPrice] ) ),
Sales[Quantity] > 5,
Sales[Discount] < 0.1
)
-- Pure SUMX Version
Sales SUMX Expensive = 
SUMX (
FILTER (
Sales,
Sales[Quantity] > 5 && Sales[Discount] < 0.1
),
Sales[SalesValue] * RELATED ( Products[UnitPrice] )
)

The Benchmarks:

Power BI Performance Analyzer:

• CALCULATE: ~210 ms
• SUMX: ~189 ms

DAX Studio (Cold Cache):

• CALCULATE: ~287 ms
• SUMX: ~293 ms

What happened?

It’s a tie. The two approaches operate at almost the same speed.

In the case under consideration, both constructs essentially impose on us the same computation model. Since row-wise multiplication between tables is necessarily imposed on us, the use of the Formula Engine (FE) will be extremely important for both of them. Neither syntax allows any bypasses. They do absolutely the same job inside and hence have the same processing time.

🧠 The Verdict: So, Which One Is Faster?

Once all execution plans have been examined, all caches have been flushed, and all server timings have been reviewed, we can safely dispose of the old myth.

• SUMXis not slow. CALCULATEis not fast.

Your DAX query performance depends entirely on architectural and evaluation considerations:

The nature of your filter: Are you using straightforward column filters, or are you imposing complex table evaluations?

Storage Engine Pushdown: Is your filter something the VertiPaq engine can evaluate by itself, or is the help of the Formula Engine required?

Context Transition cost: Are you inadvertently inducing huge row-by-row calculations by embedding a CALCULATEfunction inside a nested iterator?

In essence, the bottom line here is to stop using DAX keywords on the basis of their performance, and to pick the most optimized execution plan to achieve the logical result you want from the engine.

Sometimes CALCULATEwins. Sometimes SUMXwins. And sometimes they are absolutely identical, since what is happening behind the scenes is the same.

Have you ever found yourself in a situation where the “optimized” CALCULATEmeasure was substantially slower than a simple iterator? Join the discussion about your DAX optimization experiences in the comments below!