DAX is the formula language that powers calculations in Power BI. If you've used Excel formulas, you have a head start — but DAX works on whole tables and columns instead of individual cells, and it reacts to the filters people click in a report. This guide explains what DAX is, the two ideas that trip everyone up (row context and filter context), and how it differs from the Excel formulas you already know.

What DAX actually is

DAX stands for Data Analysis Expressions. It's a formula language Microsoft built for tabular data models — the kind that sit behind Power BI, Excel Power Pivot, and SQL Server Analysis Services. When you write a calculation in Power BI that isn't just a plain drag-and-drop sum, you're almost always writing DAX.

DAX produces three kinds of things:

  • Measures — calculations that recompute on the fly as users filter and slice a report. "Total Sales", "Profit Margin %", and "Sales vs. Last Year" are measures. This is where DAX earns its keep.
  • Calculated columns — new columns added to a table, computed row by row and stored in the model. For example, a Full Name column built from first and last name.
  • Calculated tables — entire tables generated by a formula, used less often (a date table is a common one).

A quick note on terminology: the data model behind a Power BI report used to be called a "dataset" and is now officially a semantic model. DAX is the language you use to extend that model with business logic.

The mental model: tables and relationships, not a grid

Before DAX makes sense, it helps to picture where it lives. A Power BI semantic model is a set of tables connected by relationships — usually arranged as a star schema: one or more fact tables (transactions, sales lines, events) surrounded by dimension tables (customers, products, dates, regions).

DAX assumes this structure. A well-built star schema is the single biggest factor in whether your DAX stays short and correct or turns long and fragile. When tables are related properly, a measure written on the fact table can be filtered by any dimension automatically — slice by region, by month, by product category — without you writing extra code for each one.

That's the key difference from a spreadsheet. In Excel you build the layout and the math together. In Power BI you build the model once, write measures once, and let each visual decide what gets shown.

How DAX differs from Excel formulas

DAX deliberately looks like Excel so it feels familiar — SUM, IF, AND, LEFT, and TODAY all exist and behave similarly. The differences are what matter:

Aspect Excel formula DAX
What it references A cell or range (A2, B2:B100) A whole column or table (Sales[Amount])
Where the result lives In one cell In a measure or column, shown across many visuals
Number of results One fixed value per cell A different value per filter (per row, per region, per month)
Reacts to slicers/filters No Yes — that's the whole point
Layout You arrange it on a grid The visual decides what to show

The single most important shift: DAX never points at a cell. You can't say "the value two rows up." Instead you describe the logic ("sum the amount column") and let context decide which rows are in scope. That feels strange at first, then liberating — one measure replaces hundreds of copied spreadsheet formulas.

Row context: working one row at a time

Row context means a formula is evaluated for the current row, so it can see that row's values. This is what makes calculated columns work.

Say you have a Sales table with Quantity and Unit Price columns. Here's a calculated column for line revenue:

Line Revenue = Sales[Quantity] * Sales[Unit Price]

Power BI walks down the table one row at a time. On each row, Quantity and Unit Price mean this row's values, so it multiplies them and stores the result. That awareness of "the current row" is row context.

Some functions create row context on demand — these are the iterator functions, which end in X. For example, SUMX goes row by row, computes an expression for each, then adds the results:

Total Revenue = SUMX ( Sales, Sales[Quantity] * Sales[Unit Price] )

This gives the same math as the calculated column above, but as a measure — nothing is stored, and it recalculates with whatever filters are active. As a rule of thumb, prefer measures over calculated columns when you can; they keep your model smaller and more flexible.

Filter context: the idea that makes Power BI tick

Filter context is the set of filters in effect when a calculation runs. It comes from everything the user and the report apply: slicers, the rows and columns of a matrix, the axis of a chart, page and report filters, and the visual's own settings.

Take the simplest possible measure:

Total Sales = SUM ( Sales[Amount] )

Drop it into a card and it shows the grand total. Drop the same measure into a table with Region on the rows, and each row shows the total for that region. Add a Year slicer, click 2025, and every number filters to 2025. You didn't write any region or year logic — the filter context did the work.

This is why one measure can power an entire dashboard. The number changes because the context around it changes, not because you wrote a new formula.

Changing the filter context with CALCULATE

The most important DAX function is CALCULATE, because it can modify the filter context. It evaluates an expression under filters you specify. For example, sales for only the completed orders:

Completed Sales =
CALCULATE (
    SUM ( Sales[Amount] ),
    Sales[Status] = "Completed"
)

CALCULATE takes the current context, applies your extra filter, and recomputes. Combined with time-intelligence functions, the same pattern produces things like prior-year comparisons:

Sales Last Year =
CALCULATE (
    SUM ( Sales[Amount] ),
    SAMEPERIODLASTYEAR ( 'Date'[Date] )
)

That one needs a proper date table related to your fact table — another reason the model matters.

When you actually need DAX — and when you don't

You don't need DAX for everything. Power BI auto-aggregates numeric fields, so dragging Amount onto a chart gives you a sum or average with zero code. Reach for DAX when you need:

  • Ratios and percentages that respect filters — profit margin, percent of total, conversion rate.
  • Time comparisons — year-over-year, month-to-date, running totals, rolling averages.
  • Conditional logic — flags, buckets, "active vs. churned" classifications.
  • Custom totals that the default aggregation gets wrong (averages of averages are a classic trap).

A practical tip: keep measures few and reusable. Instead of one measure per category, write one base measure and let a legend, a column split, or "Show value as → percent of total" handle the variations in the visual layer. Fewer measures mean a model that's easier to read and maintain.

A short glossary to keep handy

Measure           - a DAX calc that recomputes with filters; lives in a visual
Calculated column - a DAX calc stored row-by-row in a table
Semantic model    - the data model behind a report (formerly "dataset")
Star schema       - fact table(s) + dimension tables joined by relationships
Row context       - "the current row" a formula can see
Filter context    - the filters in effect when a calc runs
CALCULATE         - the function that changes filter context
Iterator (…X)     - SUMX, AVERAGEX, etc. — go row by row, then aggregate

Once these click, most DAX you'll meet is a combination of them: an aggregation, evaluated under some filter context, sometimes adjusted by CALCULATE, sometimes iterated row by row.

If you want to go deeper on the surrounding pieces, see our guides on building a clean star schema and Power Query vs. DAX — where to do your transformations. And for a polished look without the fiddling, the free Power BI theme generator gives you a branded color theme to drop into any report.

Get a finished report without writing a line of DAX

Learning DAX is worth it — but you don't have to wait to get value from your data. Send Instant PowerBI your raw CSV or Excel files and get back a finished, branded Power BI report: a clean star-schema model, the measures already written, and visuals laid out and ready. The data is embedded in the file, so it opens straight away in the free Power BI Desktop with no setup. Start here — share your data, get a real report back.

Frequently asked questions

What is DAX in Power BI?

DAX (Data Analysis Expressions) is the formula language used in Power BI to create measures, calculated columns, and calculated tables. It looks similar to Excel formulas but works on whole tables and columns instead of individual cells, and it recalculates based on the filters a user applies in a report. DAX is also used in Excel Power Pivot and Analysis Services tabular models.

What is the difference between DAX and Excel formulas?

Excel formulas reference individual cells (like =A2*B2) and live in a free-form grid. DAX formulas reference entire columns and tables by name (like Sales[Amount]) and never point at a single cell. DAX also reacts to report filters: a measure like Total Sales returns a different number for each region or month automatically, while an Excel cell holds one fixed result until you change the inputs.

What is the difference between row context and filter context in DAX?

Row context means a formula is evaluated one row at a time, so it can see the values in the current row — this is how calculated columns and iterators like SUMX work. Filter context is the set of filters applied to the data when a calculation runs, coming from slicers, the visual itself, the rows and columns of a matrix, and CALCULATE. Measures are driven mainly by filter context, which is why one measure shows different totals across a report.

Do I need to know DAX to use Power BI?

No. You can build many useful reports using the automatic aggregations Power BI provides (sum, average, count) by just dragging fields onto visuals. DAX becomes necessary for custom calculations like year-over-year growth, running totals, percent of total, and ratios that respect filters. If you only need standard reports, you can get a long way without writing any DAX yourself.

Build Power BI reports for a living? Do this part in minutes.

Studio turns a data export and a sentence into a valid .pbip project — TMDL model, PBIR report pages, DAX measures, branded theme. You keep the judgment calls; the clicking is done.

See Studio →