- Description
- Compteur électrique mécanique à cadrans : on paie ce que l'on consomme, au kilowattheure près.
- Source
- Mike1024 · original page
- Licence
- PD Public domain
Cost, Licensing, and Capacity
This topic assesses how well the cost of a BI platform is managed: licensing choices (Pro, Premium per user, Fabric F-SKU capacities, legacy Premium P-SKU), sizing, cost per usage…
In brief
This topic assesses control over the cost of a BI platform: licensing choices (Pro, Premium per user, Fabric F-SKU capacities, legacy Premium P-SKU), sizing, cost per usage, optimization (model size, processing windows, capacity pause, reservation), and aligning cost with value. It relies on monitoring (OPS) and performance; project-side cost/value steering is covered in PD — cost and value steering.
Anything related to pricing or licensing is volatile. The orders of magnitude below (as of 2026-10) come from third-party sources and known documentation; verify on official Microsoft pages before making any decision.
On this page
Level: 🟢→🔴 · Theme code: CST
1. Why this topic#
BI cost has two components that evolve differently: per-user licenses (linear with the number of people) and capacity (tiered with data volume and compute load). A bad choice is expensive both ways: paying for idle capacity at night, or buying licenses for a thousand occasional readers when enough capacity would make that unnecessary. A large, poorly designed model costs capacity (refreshes, queries): technical quality is a budget line item.
2. What this topic measures#
- Axis: from reactive spending to cost tied to value and continuously arbitrated.
- Key indicators: total monthly cost; cost per active user; cost per report used; average/peak capacity usage; share of capacity consumed by the top 10 models.
- Units: €/month, €/active user, % capacity.
3. The 5 levels#
| Level | Short name | Promise | Typical indicator (order of magnitude) |
|---|---|---|---|
| 1 | Reactive | The bill arrives; nobody knows what makes it up. | No breakdown |
| 2 | Known | We know what the platform costs and what goes into the bill. | Monthly cost breakdown (licenses / capacity / storage) |
| 3 | Tied to usage | We know cost per active user and per domain, and we can see unused licenses and reports. | Cost per active user; inactive licenses < 10% |
| 4 | Optimized | Sizing follows real needs; the biggest consumers are addressed. | Average usage 40–70% with peak headroom; top 10 optimized |
| 5 | Arbitrated by value | Each BI product justifies its cost with identified value, and the platform is adjusted continuously. | Cost/value tracked; annual arbitration review |
4. Milestones by level#
| ID | Milestone | Verifiable evidence |
|---|---|---|
| BI-CST-1.1 | Current licenses are listed | License inventory |
| BI-CST-1.2 | The license/capacity type of each workspace is known | Workspaces ↔ capacities table |
| BI-CST-1.3 | A BI budget owner is identified | Record |
| BI-CST-2.1 | Monthly cost breakdown (licenses, capacity, gateway, storage, upstream services) | Cost table |
| BI-CST-2.2 | User profiles are classified (creator, regular consumer, occasional) | Segmentation |
| BI-CST-2.3 | License assignment rules are written | Procedure |
| BI-CST-2.4 | The Pro / PPU / capacity selection logic is understood and documented | Decision memo |
| BI-CST-3.1 | Cost per active user is calculated | Indicator |
| BI-CST-3.2 | Inactive licenses (no activity for N days) are identified and removed | Periodic review |
| BI-CST-3.3 | Unused reports and models are identified (see GOV) | List |
| BI-CST-3.4 | Cost is allocated by domain or service (chargeback or display) | Table by domain |
| BI-CST-3.5 | Reasoned comparison of licensing scenarios against the real number of users | Simulation |
| BI-CST-4.1 | Sizing is measurement-based (Capacity Metrics), not intuition-based | Sizing report |
| BI-CST-4.2 | Top 10 capacity consumers are addressed (model, refresh, DAX) | Tracked action plan |
| BI-CST-4.3 | Processing windows are spread out to smooth load | Schedule |
| BI-CST-4.4 | Capacity pause/resizing are evaluated (night, weekend) and applied when relevant | Documented decision |
| BI-CST-4.5 | Reservation options are evaluated (annual commitment vs pay-as-you-go) | Comparison |
| BI-CST-5.1 | Each BI product has tracked expected value and cost | Value/cost record |
| BI-CST-5.2 | Annual arbitration review (keep, optimize, retire) | Meeting notes |
| BI-CST-5.3 | 12-month budget forecast tied to usage growth | Forecast |
| BI-CST-5.4 | Architecture scenarios compared by total cost (Import vs DirectQuery vs Direct Lake, SQL vs OneLake) | Decision file |
5. Detailed reading by level#
🟢 Level 1 — Reactive#
- Signs: the license “is in the Microsoft contract,” capacity “has always been there.”
- Difficulty: 1/5 · Effort: 1/5.
🟢 Level 2 — Known#
Baseline references (as of 2026-10, to be verified):
| Option | What it provides | Watch point |
|---|---|---|
| Power BI Pro (per user) | Publish, share, consume content in Pro-licensed workspaces | Each reader must also be licensed; model size and refresh frequency limits are lower than with capacity (values to verify) |
| Premium per user (PPU) | “Premium” features (large models, pipelines, more frequent refreshes) per user | Content can only be consumed by other PPU users |
| Fabric capacity (F-SKU) | Pooled compute; sizes F2 to F2048; Fabric + Power BI | Readers do not need a paid license starting at a threshold size (F64 and above, per current policy); creators still keep a Pro license or equivalent |
| Premium capacities (P-SKU) | Legacy Premium offer | Removed from purchase for new customers since July 1, 2024; migration to Fabric capacity at contract end (EA) for existing customers (to verify on Microsoft pages) |
Orders of magnitude from third-party sources (2026, to verify on Microsoft pages): Pro around USD 14 per user per month; an F64 capacity around several thousand dollars per month depending on reservation. The break-even point between Pro licenses for all readers and F64 capacity is, according to these sources, around a few hundred read-only users: this is not a rule, but an indication that there is a threshold to calculate for your user count.
- Gain: an understandable bill. Limit: cost not tied to usage.
- Difficulty: 2/5 · Effort: 2/5.
🟡 Level 3 — Tied to usage#
- Signs: using activity logs, we have the number of active users per month (≠ licensed) and cost per active user; inactive licenses are reclaimed; unopened reports are archived.
SFA running example: 450 licensed, 280 active in the last month, including 40 creators. Cost per active user is 60% higher than cost per licensed user; a plan to reclaim 90 inactive licenses is launched. (Illustrative numbers.)
- Gain: immediate reduction in unnecessary spending. Limit: licenses are optimized, compute consumption is not yet.
- Difficulty: 3/5 · Effort: 3/5.
Symptom: a user loses access to a quarterly report. Cause: “inactive” license removed using a 60-day criterion, while usage is quarterly. Fix: use an inactivity criterion that fits (180 days) or send prior alerts before removal.
🟡 Level 4 — Optimized#
- Signs: sizing is based on Capacity Metrics; the top 10 are addressed: an 8 GB model with 40% unused columns goes down to 4.5 GB; an unnecessary hourly refresh becomes daily; heavy workloads are spread out; capacity is suspended when contract and usage allow.
- Gain: sometimes one less capacity tier, i.e., cost cut in half on that line (order of magnitude).
- Limit: optimization returns diminish; each euro saved takes more effort.
- Difficulty: 4/5 · Effort: 4/5.
Before buying a higher tier, calculate capacity freed up by optimizing the five biggest consumers. Often, one month of modeling work is worth more than a year of tier difference — but not always: run the numbers.
Isolate critical workloads (executive reports) on a protected capacity or window, and let self-service experiment on a smaller capacity: a sandbox incident does not slow production.
🔴 Level 5 — Arbitrated by value#
- Signs: each BI product has a value/cost record; the annual review decides: keep, optimize, retire; the 12-month forecast includes usage growth; architecture decisions (Import vs DirectQuery, Direct Lake, SQL in PaaS vs lakehouse) include total cost, including team cost (Comparison — OneLake / Fabric vs Managed SQL Server for Power BI Reporting).
- Gain: the BI budget is defensible.
- Limit: value remains hard to measure (indirect benefit, better decisions); avoid false precision.
- Difficulty: 5/5 · Effort: 4/5.
AI features (Copilot, etc.) consume capacity and require paid Fabric capacity (starting at F2 according to Microsoft documentation) or specific billing options (as of 2026-10, to be verified): include this in cost calculations. An assistant can help simulate licensing scenarios, but prices quoted from memory must be verified.
6. Partial achievement and rating#
Common rule. “A partial 5”: value/cost records for the top 5 products out of 18 (BI-CST-5.1 = 0.5), annual review held twice (5.2 = 1), budget forecast without link to usage (5.3 = 0.5), architecture comparison without team cost (5.4 = 0.5). In small organizations (≤ 20 users), some milestones (5.2) may be “not applicable”: record the decision.
7. Moving to the next level#
Possible means (optional):
| Transition | Possible levers |
|---|---|
| 1 → 2 | License inventory; cost breakdown; user segmentation |
| 2 → 3 | Activity logs; cost/active-user indicator; license reclamation |
| 3 → 4 | Capacity Metrics; top 10 plan; processing spread; capacity pause |
| 4 → 5 | Value/cost records; annual review; forecasting; compared architecture files |
Pitfalls:
- False positive: low cost because users moved to Excel. Lower cost with lower usage is a warning signal, not a victory.
- Goodhart: targeting the lowest cost per user pushes you to under-license or saturate capacity.
- Underestimating team cost and maintenance debt: often higher than licensing.
- Making decisions based on blog prices: always confirm on official pages and the real contract (discounts, commitments).
8. See also#
- Neighboring topics: OPS · PRF · GOV · MOD
- Other matrices: PD — cost and value steering · PI — budget, value, and benefits · DL — performance and scalability
- Content: Comparison — OneLake / Fabric vs Managed SQL Server for Power BI Reporting · OneLake + SaaS Mobile Apps: Overview · SQL Server in SaaS — overview · Cross-Cutting Power BI Good Practices · Source control for data: SQL and Power BI
✻ Written by Claude Sonnet 5.5
