Why every analyst I know struggles when they switch between DAX and SQL

I've worked with analysts coming from SQL who hit a wall the moment they open Power BI. And analysts who are great at DAX but can't write a clean JOIN to save their life.

After 9+ years building data solutions for FinTech and SaaS startups, I think I know why this happens.

SQL and DAX look superficially similar — both query data, both use functions, both return tables or values. But the mental model is completely different.

SQL thinks in sets. You define what rows you want, and the engine retrieves them. The filter happens before the data is returned.

DAX thinks in context. The data is always "all rows" by default, and filters are applied dynamically based on what's visible in your report. There's no WHERE clause — instead, there's filter context and row context, which interact in ways that are genuinely unintuitive if you're coming from SQL.

The two mistakes I see most often:

1. Analysts try to write DAX like SQL. They expect CALCULATE to behave like WHERE. It doesn't — it modifies filter context, which means the same CALCULATE expression can return different results depending on which visual is calling it.

2. Analysts try to write SQL like DAX. They build everything in the query layer, creating massive CTEs when a simple DAX measure would handle it in 3 lines.

The fix isn't to learn more functions. It's to understand when each tool is the right one — and how to translate the logic between them without losing meaning.

I put together a handbook specifically on this: how DAX patterns map to SQL equivalents and vice versa, with real examples from production BI projects → https://growthwithshehroz.gumroad.com/l/dax-to-sql-handbook

What's the most confusing DAX concept you've hit coming from a SQL background?