The mental model shift that trips up every analyst moving from SQL to DAX

I've seen this pattern dozens of times working with BI teams at FinTech and SaaS startups.

An analyst who writes great SQL sits down with Power BI for the first time. Within an hour they're frustrated. The numbers don't match. A simple "total sales" measure returns something unexpected.

The problem isn't Power BI. It's that DAX operates on a fundamentally different mental model.

In SQL, you think in rows. You write a query, filter the rows you want, aggregate them, done. The filter context is explicit — you wrote it in the WHERE clause.

In DAX, the filter context is implicit. It flows in from the visual, from slicers, from relationships between tables. Your measure doesn't know how it's going to be filtered when you write it. It adapts at runtime.

This is why CALCULATE exists — it's not just a function, it's the mechanism for explicitly modifying that implicit filter context. Once you internalize that, DAX starts to make sense.

The second trip-up: DAX relationships are directional. A many-to-one relationship filters one way by default. In SQL you JOIN however you like. In DAX, cross-filtering the wrong direction causes silent wrong answers — the worst kind of bug.

I documented the exact conversion patterns (aggregations, time intelligence, semi-additive measures, row context vs filter context) for analysts navigating both worlds: https://growthwithshehroz.gumroad.com/l/dax-to-sql-handbook

What was the DAX concept that finally clicked for you — and what made it click?