The one mental shift that makes DAX click for SQL developers

Most analysts who come from SQL hit the same wall in DAX: they try to write row-by-row logic, and DAX doesn't work that way.

In SQL, you filter rows then aggregate. In DAX, the engine works backwards - you write a measure, and DAX determines the filter context dynamically based on where that measure is placed in the report. This is why the same formula behaves differently in a matrix vs. a card visual. Not a bug. That's the design.

Three patterns that break most SQL developers in DAX:

1. Treating CALCULATE() like a WHERE clause - it's actually the entire filter context engine
2. Expecting relationship behavior like a SQL JOIN - DAX propagates filters through relationships, it doesn't join rows
3. Writing time intelligence without a proper date table - DATESINPERIOD needs a marked date table, not just a date column

I spent months documenting 15+ of these DAX-to-SQL conversion patterns from real client projects - cases where the same business logic had to live in DAX one day and SQL the next depending on which layer owned it.

I packaged those patterns into the DAX to SQL Conversion Handbook: https://growthwithshehroz.gumroad.com/l/dax-to-sql-handbook

What's the pattern that tripped you up most when you first moved from SQL to DAX?