DAX and SQL are qualitatively different languages. They serve different use cases entirely. DAX is designed solely for analytical queries using dynamic context

DAX and SQL are qualitatively different languages. They serve different use cases entirely. DAX is designed solely for analytical queries using dynamic context (so you don't have to code for every user selected filter or relationship dependency in your model.) Its meant to be written once and then used interactively by your users. It has tons of helper functions like time intelligence, iterators and generators .. SQL is obviously much broader in scope and functionality, but to match the level of built in context driven dynamism of DAX would require a frankly unmaintainable mess. So yeah if you just need an answer to a single specific analytic query, just write a SQL query. But if you need to create a measure to show weighted average pricing for any user selected combination of equities, time periods, markets, vendors, and 500 other dimensional attributes - and then create 5 more measures on top of that to show year to date, year over year, performance vs. overall market, simulated demand at a 5% decrease in price, and price excluding large institutional purchases - DAX is your friend.