Capacity planning is not a choice between “small” and “large.” It is a description of how ingestion, Spark, semantic models, reports, and users share compute over time.
The average workload can look harmless while a refresh window, notebook run, and morning report traffic collide. Plan for the collision, not only the average.
Start with workload patterns
Before choosing a capacity, answer:
- How many people query the solution regularly?
- Are queries interactive, scheduled, or both?
- Is the environment mostly Lakehouse and SQL work, or mostly semantic-model queries?
- How often do pipelines, notebooks, and refreshes run?
- What growth is likely over the next three to six months?
Those answers are more useful than “we need a big capacity.”
A worked example
Suppose the environment has:
- one Lakehouse with 3-5 TB of data;
- three or four pipeline refreshes per day;
- a semantic model used by 20 people;
- nightly notebook processing; and
- several operational quality checks.
That is no longer a small test. Ask:
- Is demand steady or spiky?
- Do pipeline windows overlap?
- Does processing run during business hours?
- Do several workspaces compete for the same capacity?
The design depends on those overlaps as much as on the data volume.
A practical planning process
1. Classify the workloads
Separate:
- ingestion and transformations;
- notebook or Spark processing;
- interactive BI and semantic-model queries;
- report refreshes and exploration; and
- orchestration and scheduled jobs.
They have different timing and concurrency characteristics.
2. Map peak windows
Write down when the environment is busiest. A common pattern is:
- 08:00-10:00 for data refreshes;
- 11:00-14:00 for report exploration; and
- 18:00 for batch processing.
If those windows overlap, the capacity can feel constrained even when the daily average is moderate.
3. Check contention
Look for simultaneous notebooks, report openings, pipeline refreshes, and semantic-model processing. Repeated overlap is a capacity signal, not random bad luck.
4. Add headroom
Start from the current baseline, add realistic quarterly growth, include month-end or quarter-end spikes, and leave room for recovery. A capacity that works only at 95% utilization is fragile.
Trial capacity is for learning, not certification
With a Fabric trial, test a small but representative workload:
- run the pipeline at realistic frequency;
- exercise concurrency;
- create a refresh spike;
- observe notebook or Spark behavior; and
- record what must change before the next capacity level.
“It worked once” does not answer the production sizing question.
Operating habits that help
- Separate development, test, and production workspaces where possible.
- Avoid scheduling heavy processing in the same window as known report peaks.
- Record normal utilization before and after major changes.
- Review the capacity plan after new models, pipelines, or user groups arrive.
- Document which workload owns each peak.
The takeaway
A useful capacity plan names the workloads, their peak windows, their concurrency, and the growth assumption. Choose the capacity only after those four things are visible. That turns an expensive guess into a testable design.
Loading comments…