I Tested “Avoid SUMX” Against 10.9 Million Rows. It Went Both Ways.

The standard DAX advice — and something I've followed on production work — is to avoid SUMX where a simpler aggregation exists, on the assumption that row-by-row iteration is slower than a columnar scan. I put it on the clock with Performance Analyzer, on 10.9 million rows of NYC taxi data, two different ways.

Test 1 — SUMX combining three columns

Total SUMX   = SUMX ( nyc_taxi, fareAmount + tipAmount + tollsAmount )
Total Simple = SUM ( fareAmount ) + SUM ( tipAmount ) + SUM ( tollsAmount )

Three separate SUM() calls force three separate storage-engine scans, stitched together in the formula engine afterward. A single SUMX reads all three columns in one pass.

SUMX: 303ms. Three SUMs added together: 2015ms. SUMX won by nearly 7x.

Test 2 — SUMX with nothing to fold

Total SUMX   = SUMX ( nyc_taxi, nyc_taxi[fareAmount] )
Total Simple = SUM ( nyc_taxi[fareAmount] )

Here SUMX is wrapping a single column with no arithmetic to combine. SUM() already does a direct single-column scan and needs no help — so SUMX just adds iteration overhead for nothing.

SUMX: 460ms. Plain SUM: 435ms. SUM won.

The rule that actually holds

It isn't “avoid SUMX” and it isn't “prefer SUMX.” It's: SUMX helps when it lets the engine do one pass instead of several. It costs when it's wrapping something a native aggregation already does directly, with zero help needed.

General DAX guidance points in a direction. The real answer for your calculation comes from Performance Analyzer on your actual data volume.

What I take from this

• The same function was ~7x faster in one case and slightly slower in the very next
• The deciding factor is whether SUMX collapses multiple scans into one
• Test the specific calculation at real volume; don't apply the blanket rule blind