Ask anyone who's tried to learn Power BI seriously and they'll point to DAX as the thing that separates the curious from the committed. There are entire courses, certifications, and YouTube videos built around mastering it. And for a long time, that approach was the way to go.

But the landscape has shifted tremendously in the last couple years. Copilot in Power BI can generate a measure for you. Quick measures cover a surprising percentage of what most reports actually need. And if you're working with a well-modeled semantic layer, a lot of the heavy lifting is already done before you open the report canvas.

So where does that leave DAX proficiency as a skill? Somewhere between "required fluency" and "knowing when to call for backup." My take on this is: most analysts don't need to write complex DAX, but they do need to understand one fundamental distinction, because getting it wrong can really break things.

Measures vs. Calculated Columns

At the core of DAX are two ways to create a new field: a measure and a calculated column. They look similar on the surface. Both are written in DAX, and both show up in your field list, but they behave in fundamentally different ways. And mixing them up creates problems that aren't always obvious until something is wrong.

Calculated Columns. A calculated column is evaluated row by row at data refresh time and stored in the model. Think of it like adding a new column to your source table, it exists physically in memory. Because it's computed at the row level, it has access to other values in the same row, which makes it useful for things like categorizing records, concatenating fields, or creating a lookup key. The tradeoff is that it inflates your model size, and its value is fixed at refresh, it can't recalculate based on filter context the way a measure can.

Measures. A measure doesn't exist as a stored value. It's evaluated dynamically at query time, in response to whatever filter context is active in your visual. That's what makes measures powerful, the same measure can return a different result depending on what's selected on the page. They don't add to your model's memory footprint, and they're the right tool for anything aggregated: totals, averages, ratios, YTD calculations. Almost every KPI card or chart value should be a measure.

The practical rule of thumb. If you're creating something that describes a row like a label, a bucket, a flag then that's a calculated column. If you're creating something that summarizes or aggregates data, anything you'd want to change based on a filter or slicer, that's a measure. Getting this backwards is one of the most common errors in Power BI models: a calculated column used where a measure should be will give you results that look right until a filter is applied, and then they don't.

What does "GPU" stand for?

A. General Processing Unit
B. Graphical Program Utility
C. Graphics Processing Unit
D. Global Parallel Unit

Answer at the bottom of this issue

Calculated Columns and Measures in DAX by Marco Russo @ SQLBI
Digs into evaluation context as the core distinction, measures are evaluated in the context of the cell in a report or DAX query, while calculated columns are computed row by row in the table they belong to. Read more →

Measures vs Calculated Columns in DAX and Power BI by Jessica Hill
A walkthrough with the supermarket sales dataset that shows both approaches producing the same output on the surface, then reveals why they behave differently under the hood. It also covers why measures require aggregation functions when referencing columns, which trips up a lot of beginners. Read more →

Write DAX Queries with Copilot by Microsoft Learn
The official Microsoft documentation on Copilot's DAX query writing capability in Power BI Desktop and the browser. Copilot uses the model metadata tables, columns, and measures, to generate DAX queries in context of the semantic model you're working with. Read more →

Summarize any article with VizBuddy

DuckDB #data-visualization #productivity
An in-process analytical database you can run from a notebook or the command line with zero setup. Worth including because it's the kind of tool that rewards understanding why columnar analytics is fast rather than just memorizing syntax. Free and open source.

Evidence #data-visualization #productivity
A framework for building BI reports as code (SQL + Markdown), version-controlled like anything else. A good example of the "judgment travels, tooling changes" thesis in practice: the report logic outlives the dashboard tool. Open source.

▶️ We tested the New Power BI Report Skills: The Future of AI-Powered Reporting? [Step by step demo] by Guy in a Cube (8 mins)
In this video, Marthe tests the new Power BI Report Skills experience and shows how AI is changing the way reports are created, refined, and delivered.

What does "GPU" stand for?

A. General Processing Unit
B. Graphical Program Utility
C. Graphics Processing Unit ✅
D. Global Parallel Unit

The term GPU was popularized by NVIDIA when it released the GeForce 256 in 1999, marketing it as the world's first GPU. Originally designed to offload graphics rendering from the CPU, GPUs are now at the center of the AI revolution, their ability to handle thousands of parallel computations simultaneously makes them ideal for training large language models.

📖 Read more → NVIDIA Blog: Game-Changer - How the World's First GPU Ignited the AI Era

Newsletter publishing is hard work and it’s just me running the show here. If you ever feel like extending a thanks, idea, or insult you can do that here.
Or email me directly at → [email protected]

If you’re feeling generous, I also keep an Amazon Wishlist of books and tools I’m interested in.