Why most BI analysts struggle switching between DAX and SQL

The mental model is fundamentally different — and that's the real problem.

After working with FinTech and SaaS startups as a BI consultant, I see the same friction constantly: analysts fluent in DAX freeze up in SQL, and SQL-first developers can't wrap their heads around DAX measures.

Here's why:

DAX operates on filter context. You're not writing what data to fetch — you're defining how a measure should behave when filters are applied. Everything is implicit.

SQL operates on sets. You explicitly tell the engine what rows to include, how to join them, how to aggregate.

This creates predictable blind spots:

— Trying to replicate CALCULATE() in SQL (the equivalent is conditional aggregation or a subquery, not a single function)
— Treating RELATED() like a field reference instead of recognizing it maps to a JOIN
— Time intelligence in DAX is one function; in SQL it's explicit date arithmetic every time

The fix isn't starting from scratch. It's translation. Once you see that CALCULATE(SUM([Revenue]), SAMEPERIODLASTYEAR(Dates[Date])) is just a self-join with date filtering in SQL, it clicks.

I've been documenting exactly these patterns — DAX constructs most analysts already know, mapped to their SQL equivalents: https://growthwithshehroz.gumroad.com/l/dax-to-sql-handbook ($9)

What's the DAX pattern you found hardest to translate into SQL?