Lesson 5 of 8 · 11 min
Sizing a Capacity With Evidence
“Which SKU do we need?” is usually asked as if it had one correct answer. It does not. A good sizing answer is a range, the assumptions behind it, and the point at which you would change your mind.
This lesson covers two situations: sizing an existing capacity that is being re-planned, and sizing for a workload that has not been built yet.
The envelope
Whatever the workload, the decision comes down to one sum:
Required capacity envelope =
existing smoothed baseline
+ incremental demand from new or growing workloads
+ operating headroomEach term has a different source of evidence.
- Existing baseline comes from the Capacity Metrics app, after the optimizations in lesson four. Sizing on unoptimized demand locks waste into the budget.
- Incremental demand comes from an estimate first, then a pilot.
- Headroom is a policy decision. It is the share of the capacity you keep free so ordinary peaks do not become incidents.
Headroom is a policy, not a number
There is no universal headroom figure. Choose it based on how much an incident costs you.
A capacity that serves executive reporting during business hours needs more headroom than a development capacity where a delayed job is an inconvenience. A capacity with surge protection and a tested scale-up runbook can run closer to its limit than one with neither. Write the chosen headroom down with the reason, because the next person to review the capacity will ask.
Estimating before a workload exists
For a new data platform, the Fabric SKU Estimator (preview) is a reasonable first hypothesis. It asks for compressed data size, daily batch cycles, table counts, and the workloads you plan to use, then recommends a viable SKU with a breakdown.
Treat that output as a starting point, not a commitment. It cannot know your query patterns, your refresh frequency, or how many people will open a report at 9:00 AM on Monday.
The most reliable evidence is a pilot on a trial or a small pay-as-you-go capacity, using representative data and representative schedules. Run it for at least a full business cycle, including the heaviest day if you can, then read the result in the Capacity Metrics app.
Engineering workloads are system-shaped
Spark jobs, pipelines, warehouse loads, and refreshes are mostly driven by data volume, runtime, and schedule. They are planned and repeatable, so a representative run is good evidence. Size them from:
- CU-seconds per run, measured in the pilot
- Runs per day, from the schedule you actually need
- The processing window and how much of it overlaps with interactive use
AI workloads are behavior-shaped
Data agents and Copilot are driven by people: how many use them, how often, how long their questions are, and how long the answers are. Adoption can change demand far faster than any pipeline schedule.
A Fabric Data Agent question creates two kinds of consumption:
- AI processing, reported as the AI Query operation, priced by tokens. Microsoft documents these rates:
| Component | Consumption |
|---|---|
| Uncached input | 100 CU-seconds per 1,000 tokens |
| Cached input | 10 CU-seconds per 1,000 tokens |
| Output | 400 CU-seconds per 1,000 tokens |
- Generated queries against the warehouse, semantic model, or KQL database, billed to that engine as normal.
Estimate both, separately. Build three request classes (simple, standard, complex) with token counts for each, then multiply by users, questions per user, and working days. In a pilot, filter the Capacity Metrics app to the AI Query operation to measure the first number, and to the source items to measure the second. Capture the 90th percentile, not just the average, because long conversations grow the prompt.
If AI usage spreads across many workspaces, you can designate a Fabric Copilot capacity so AI usage is billed and monitored in one place. Generated queries are still charged to their source engines.
An illustrative envelope
The numbers below are fictional. They show how to present a range.
| Term | Expected case | High-adoption case |
|---|---|---|
| Weekday smoothed baseline, after optimization | 36 CUs | 36 CUs |
| New lakehouse and refresh workload | 8 CUs | 10 CUs |
| Data agent AI processing and generated queries | 4 CUs | 10 CUs |
| Subtotal | 48 CUs | 56 CUs |
| Headroom policy | 25% | 25% |
| Envelope (subtotal ÷ 0.75) | 64 CUs | about 75 CUs |
The expected case fits an F64 exactly, with no margin for error. The high-adoption case does not. F SKUs come in fixed steps (F2, F4, F8, F16, F32, F64, F128, and up), so the next step is F128.
That does not mean “buy F128.” It means the decision depends on the levers in the next two lessons. Options include moving Spark to on-demand billing, isolating the agent workload on its own capacity, phasing the agent rollout, or starting on F64 with a tested scale-up plan and a trigger condition. The point of the envelope is to make that conversation explicit.
Do not forget licensing
If the capacity serves many Power BI viewers with free licenses, anything below F64 requires each of them to have a Pro or Premium Per User license. Include that cost in the comparison before recommending a smaller SKU.
Exercise: build your envelope
Using your baseline and the fixes from lesson four, fill in the envelope for your capacity or a planned one.
| Term | Expected | High | Evidence source |
|---|---|---|---|
| Smoothed baseline | Capacity Metrics app, week of: | ||
| New workload 1 | Estimator, pilot, or calculation | ||
| New workload 2 | |||
| AI processing | Token model or pilot | ||
| AI generated queries | Pilot | ||
| Headroom policy and reason | |||
| Envelope in CUs | |||
| Smallest SKU that fits |
Then write the trigger that would change the decision, such as “if weekday background exceeds 70% for two consecutive weeks, scale to the next SKU or isolate the largest workload.”
Carry this forward
An envelope tells you how much compute you need. It does not tell you how to protect critical work when demand temporarily exceeds it. That is the subject of the next lesson.