Analytics & BI Tools · Chapter 2 of 8
Power BI, in practice
The volume leader, for reasons that are mostly commercial. What it is genuinely good at and where it hurts.
Power BI's dominance in enterprises is substantially a distribution story — it arrives bundled with Microsoft agreements many organisations already have, which makes the marginal cost look like zero. That is a real advantage and it is not a technical one, so evaluate the technical part separately.
What it genuinely does well
- Cost of entry. Per-user licensing that is very cheap relative to competitors, and often already paid for.
- Power Query for preparation — genuinely capable, and the same engine appears in Excel, which matters because your analysts already know it.
- DAX is powerful for time intelligence and complex measures. Year-on-year, rolling averages and running totals are far easier than in most competitors.
- Excel integration, which is not a joke — the ability for a finance user to pivot against a governed model in the tool they actually use removes an enormous amount of shadow reporting.
- Deep Microsoft integration — Entra ID, Teams, Fabric, and increasingly Copilot.
Where it hurts
DAX has a steep and unusual learning curve. Filter context and row context are genuinely hard concepts and the error messages are unhelpful. Budget for this rather than assuming SQL skills transfer.
Import mode versus DirectQuery is a real architectural decision. Import is fast and means a copy of the data with a refresh schedule; DirectQuery is live and pushes load onto the warehouse, often with disappointing latency. Getting this wrong is the most common Power BI performance problem.
Governance sprawl. Cheap licensing plus easy publishing produces thousands of workspaces and reports, most abandoned. Without deliberate certification and lifecycle policy this becomes unmanageable within two years.
Version control is awkward. Report files are binary artefacts; treating them like code needs deliberate effort.
The Power BI question you will be asked
“Import or DirectQuery?” The answer that lands: import when the data fits and the freshness requirement is measured in hours, because performance is far better and the warehouse is not hit by every filter click. DirectQuery when the data is too large to import, when freshness must be near real-time, or when the warehouse holds row-level security you must not duplicate.
Then the nuance that shows experience: DirectQuery performance is a warehouse problem, not a Power BI problem — every visual becomes a query, so an unclustered table on the other end makes the dashboard feel broken.