1
0 Comments

Why switching between DAX and SQL trips up most BI analysts

After 9 years building Power BI reports and SQL Server data warehouses for FinTech and SaaS startups, I keep seeing the same frustration play out.

A SQL analyst sits down with a Power BI model and gets completely lost at CALCULATE. A DAX expert joins a T-SQL project and can't figure out why their logic doesn't transfer.

The core issue: DAX and SQL solve similar problems from fundamentally different mental models.

SQL thinks in sets and rows — you filter before you compute.
DAX thinks in evaluation contexts — you compute first, and filter context shapes the result.

Patterns that trip most people up:
— CALCULATE isn't just a filter, it modifies filter context
— Row context vs filter context (almost everyone gets burned by this the first time)
— Time intelligence in DAX looks like SQL date logic but behaves very differently
— WHERE in SQL ≠ FILTER in DAX — they execute at different points

Once you internalize the context model, moving between the two gets much faster. Until then you're translating between two dialects without a dictionary.

I documented the conversion patterns I use most when moving client reports between SQL Server and Power BI: https://growthwithshehroz.gumroad.com/l/dax-to-sql-handbook

What's the concept that finally clicked for you — in either direction?

on May 20, 2026