Analytics & BI Tools · Chapter 6 of 18
Choosing, with real scenarios
Five situations, and what actually fits each. The answer is rarely the best tool.
Tool selection questions are decided by context far more than by capability. Here are the scenarios that recur, and what usually fits.
| Situation | Usually fits | Because |
|---|---|---|
| Microsoft-heavy enterprise, thousands of report consumers, tight budget | Power BI | Licensing is already paid for and per-consumer cost is the dominant term at that scale |
| A hundred genuine analysts doing exploratory work | Tableau | Exploration is what it is best at, and the creator count is small enough that cost is bearable |
| Numbers must agree across the company, and they currently do not | Looker or a semantic layer | The problem is definition governance, not visualisation |
| Startup, small team, everything in one warehouse | Metabase or Superset | Open source, cheap, adequate — and the money is better spent on the warehouse |
| Regulated function needing auditable, analyst-built preparation | Alteryx, with a promotion path | Visible workflow logic satisfies audit; the promotion path prevents shadow production |
What actually decides it in practice
- Who your users are — analysts who explore, or consumers who read. This single question decides more than any feature comparison.
- What you already own. A bundled tool at effectively zero marginal cost beats a better tool at full price for most organisations, and pretending otherwise wastes everyone's time.
- Whether you have someone to model. A semantic layer needs an owner; without one, buying Looker gets you an expensive report tool.
- Where the metric definition will live. Decide this before choosing a tool, and the tool choice narrows considerably.
- Migration cost is usually underestimated by a factor of two or three, because rebuilding reports is the visible part and rebuilding trust in the numbers is not.
The answer that lands in an interview
Not a favourite. Establish the users, the existing estate, and where definitions live — then recommend, and say what you would give up. “I would take Power BI here because the consumer count makes licensing the dominant cost, and I would accept weaker exploratory analysis and invest the saving in a proper semantic layer” is a senior answer.
Naming what you sacrifice is what separates a recommendation from a preference.
Five situations, worked
| Situation | What actually fits | Why not the obvious answer |
|---|---|---|
| 200-person company, one analyst, warehouse already in place | Whatever the analyst already knows well | Tool choice is worth less than the analyst's fluency. A 'better' tool they must learn costs months of output |
| Numbers must agree across finance, sales and ops | A semantic layer — in the BI tool or the warehouse | Self-service breadth is the wrong optimisation here. The problem is agreement, and agreement needs one definition |
| Thousands of viewers, a handful of authors | Import-model tooling with capacity pricing | Per-user pricing at that ratio punishes exactly the behaviour you want. The shape of the pricing matters more than the rate |
| Embedding analytics in a customer-facing product | Usually neither of the big two — an embedded-first product, or build it | Enterprise BI tools are built for internal users. Licensing, theming and multi-tenancy all fight you |
| Migrating off a legacy reporting estate | Rebuild the top 20 reports, retire the rest | Nobody wants to hear this. Most of a legacy estate is unused; a like-for-like migration ports the dead weight and costs a year |
The answer is rarely the best tool
Every one of the five above turns on something other than tool capability — existing skills, the shape of the pricing, who the consumers are, whether the estate is worth porting.
That is not a comment about this category being undifferentiated. It is that the capability gap between the leading tools is now smaller than the gap between a well-run and a badly-run deployment of any of them — the same conclusion the interview-validity chapter reaches about selection methods, for the same reason.
So the evaluation questions that discriminate are not feature questions: who will author, who will consume, does the metric definition live in one place, what does the pricing shape encourage, and what happens to the logic if we leave.
And the decision that outlives the tool is where the definitions live. Push them into the warehouse and the BI tool becomes a rendering layer you can replace. Leave them in the reports and you have bought a migration project for whenever you change your mind.
Run a bake-off on your own data with your own hardest question, not on a vendor's demo dataset. The demo is chosen to work.
Check yourself