The BI developer's toolbelt

At a glance

Performance Analyzer

• What it does: records how long each visual takes, split into DAX query, visual display and other, and lets you copy the query.
• When you need it: a page is slow and you don't know which visual, or whether the time is in the query or the rendering.
• When you don't: the slowness is refresh, not report interaction.
• First exercise: View → Performance Analyzer → Start recording → Refresh visuals. Sort by duration; copy the slowest visual's query into DAX query view.
• Real scenario: Sprint 04: the 18-second page.

DAX query view

• What it does: a query editor inside Desktop: write EVALUATE queries, define and test measures, and update the model from the query.
• When you need it: debugging a measure without a visual in the way; inspecting the query a visual generates; quick data checks.
• When you don't: you need engine-level timings (use DAX Studio).
• First exercise: EVALUATE SUMMARIZECOLUMNS ( DimProduct[Category], "Sales", [Net Sales] ) and compare with the visual.

DAX Studio

• What it does: connects to Desktop or the XMLA endpoint; runs queries with Server Timings (storage engine vs formula engine time, SE queries and cache hits) and query plans; includes VertiPaq Analyzer, export to files and benchmarking. Version 3.6 added a preview Delta Analyzer for the Delta metadata behind Direct Lake models.
• When you need it: a measure is slow and you need to know why (formula engine heavy, too many storage-engine queries, callbacks, large materialisations).
• When you don't: the problem is visual rendering or too many visuals.
• First exercise: paste a slow visual's query, turn on Server Timings, run it with a cleared cache, and read the split between FE and SE.
• Docs: daxstudio.org.

VertiPaq Analyzer

• What it does: shows every table and column's size, cardinality, encoding and the cost of relationships and hierarchies (View Metrics in DAX Studio; also in Tabular Editor 3).
• When you need it: the model is big, refresh runs out of memory, or you are about to add a column and want to know what it costs.
• When you don't: small models that refresh comfortably.
• First exercise: View Metrics on any model; find the column with the highest cardinality and ask whether anyone needs it (timestamps with seconds, GUIDs and free-text columns usually top the list).

Tabular Editor

• What it does: edits the model's metadata directly: measures, display folders, descriptions, calculation groups, perspectives, translations, partitions; C# scripts for bulk changes; works on PBIP/TMDL files, Desktop and the XMLA endpoint.
• When you need it: more than a handful of measures to create or change consistently; calculation groups; anything you'd otherwise click 200 times.
• When you don't: a one-off measure in a small model.
• First exercise: script "add a description to every measure that doesn't have one" and "move every measure starting with % into a Ratios folder".
• Editions: Tabular Editor 2 is free and open source; Tabular Editor 3 is commercial with a richer editor and VertiPaq Analyzer built in.

Best Practice Analyzer

• What it does: runs rules over the model (naming, hidden keys, descriptions, data types, DAX anti-patterns, performance) and reports violations, some with automatic fixes.
• When you need it: more than one developer works on the model, or you want reviews to focus on logic instead of style.
• When you don't: never, really; but start with a small rule set so the results are read rather than ignored.
• First exercise: load Microsoft's BPA rules, run them on the starter model, and fix the top three categories. Then see the best-practice library.

ALM Toolkit

• What it does: compares two semantic models (Desktop, PBIP, XMLA endpoint) object by object and deploys selected differences, metadata only, without overwriting data partitions.
• When you need it: promoting a measure change to a large Production model without a full redeploy and refresh; reviewing what changed between two versions.
• When you don't: your team deploys from Git with deployment pipelines or fabric-cicd and never edits Production directly.

SSMS

• What it does: SQL Server Management Studio connects to the XMLA endpoint of a Premium or Fabric workspace: script the model as TMSL, process tables and partitions, run DMV queries, manage roles.
• When you need it: refreshing one partition, investigating a large model's partitions, scripting maintenance. Also your SQL source work.
• When you don't: routine development (Desktop and Tabular Editor are faster).
• Practise: XMLA, TOM and TMSL.

VS Code

• What it does: a code editor for PBIP project folders: TMDL, report JSON (PBIR), deployment scripts and pipelines, with Git built in and a TMDL extension for syntax highlighting.
• When you need it: reviewing changes, resolving merge conflicts, editing many objects at once, writing automation.
• When you don't: designing visuals (that's Desktop's job).

Git

• What it does: version control: history, branches, pull requests and the ability to undo. With PBIP, a model and a report are folders of text files, so Git works on them like on code.
• When you need it: from the moment a second person touches the model, or the first time you wish you could go back to Tuesday's version.
• First exercise: save the starter model as PBIP, commit, change one measure, and read the diff. Then do Ship Power BI like software.

Fabric Capacity Metrics

• What it does: a Microsoft app that shows capacity usage (CU) over time, by item and operation, including throttling and overages.
• When you need it: reports are slow for everyone at the same time of day; refreshes queue; users see throttling errors; you're sizing a capacity.
• When you don't: Pro or PPU workspaces without a capacity.
• Real scenario: the capacity section of the production runbook.