F2, F8 or F64? Picking the Right Microsoft Fabric Capacity for 10, 80 and 300 Report Viewers

Scenario: One BI Team, Three Audience Sizes

Imagine a central BI team that has:

• A lakehouse (or warehouse) with a few fact tables
• 10–15 semantic models powering Power BI reports
• A mix of Import and Direct Lake models
• Scheduled refreshes every 30–60 minutes for operational datasets

The only thing that changes between our three cases is how many people regularly view the reports:

1. Small team – about 10 regular report viewers
2. Mid-size business unit – about 80 regular report viewers
3. Large department / multi-region – about 300 regular report viewers

We’ll assume Fabric is used primarily for:

• Power BI report viewing in the service
• Scheduled refreshes
• Light ad‑hoc analysis (not heavy Spark or massive ML workloads)

If your environment is heavy on data engineering (Spark, Dataflows Gen2, notebooks) the same logic applies, but the breakpoints move up because you burn more capacity on compute.

What F2, F8 and F64 Actually Change

Fabric capacities scale mostly along three axes:

• Compute power – how fast queries and refreshes run
• Concurrency – how many operations can run at once
• Memory – how much data can be held in memory concurrently

Some key behaviours that matter for sizing:

• Fabric items must be assigned to a capacity to use Fabric features (lakehouses, warehouses, Direct Lake, etc.). Power BI workspaces can run on shared capacity with Power BI Pro or Premium per user, but Fabric workloads (and Premium-like features such as large model sizes and advanced refresh) require a Fabric capacity.
• Capacity units are shared across all workloads assigned to that capacity. A heavy refresh or Spark job can slow down report queries if they overlap.
• Throttling and queueing: when the capacity is saturated, operations are queued or throttled. Users feel this as slow report load times, refresh delays, or timeouts.
• Scaling options: you can scale up (F2 → F4 → F8…) or scale out (multiple capacities) and you can pause capacities to save cost when idle.

The exact numeric limits (memory per capacity, max concurrent queries, background jobs, etc.) are documented and vary by SKU. Rather than reproduce tables, we’ll focus on typical impact for the three viewer sizes.

Step 1 – Estimate Your Load: Viewers, Concurrency, and Refresh

Before talking F2 vs F8 vs F64, you need a rough load profile.

For our scenario, we’ll define three dimensions:

1. Peak concurrent viewers

   • Small team (10 viewers): maybe 3–4 people hitting reports at exactly the same time.
   • Mid-size (80 viewers): 15–25 concurrent around the morning peak.
   • Large (300 viewers): 60–100 concurrent during weekly or month‑end crunch.

2. Model size and type

   • Operational models: 1–5 GB in memory, Import or Direct Lake.
   • Reference/slowly changing: smaller, but still in memory during use.
   • For sizing, think about total memory footprint of active models at peak, not just disk size.

3. Refresh and background workloads

   • Import models refreshing every 30–60 minutes.
   • Dataflows Gen2 or pipelines landing data into the lakehouse.
   • Occasional notebook or Spark jobs.

The more these overlap with report viewing, the more capacity you need.

Case 1 – 10 Report Viewers: F2 Is Usually Enough

Profile

• 10 regular viewers, mostly business analysts
• 3–4 concurrent users at peak
• 3–5 semantic models, each a few GB in memory
• Refresh every 60 minutes, staggered

Why F2 typically works

For a small team, the key is avoiding Premium‑like overkill while still unlocking Fabric features.

An F2 capacity gives you:

• Sufficient compute for light to moderate Import and Direct Lake models
• Enough concurrency for a handful of simultaneous report queries and background refreshes
• Access to Fabric workloads (lakehouse, warehouse, notebooks, Dataflows Gen2)

In practice, with 10 viewers:

• Report performance: if models are reasonably designed (no huge single‑table monsters, sensible aggregations), most visuals render within a few seconds under F2.
• Refresh: hourly refreshes of several GB models are usually fine, as long as you stagger them.
• Data engineering: light Spark or Dataflows usage fits, but heavy ETL overlapping with peak report usage can saturate the capacity.

When F2 is too small

You’ll feel F2 strain when:

• A single Import model grows into tens of GB in memory.
• Multiple refreshes overlap with a peak viewing window.
• Someone runs large notebook jobs during business hours.

Symptoms:

• Reports intermittently slow at peak times.
• Refreshes slipping and completing later than scheduled.

If that happens, first:

• Stagger refreshes away from viewing peaks.
• Move heavy Spark jobs to off‑hours.

If you still see pain, scaling to F4 is usually enough; jumping straight to F8 for only 10 viewers is rarely cost‑effective.

Case 2 – 80 Report Viewers: F8 Is the Sweet Spot

Profile

• 80 regular viewers across one or two departments
• 15–25 concurrent users at peak
• 10–15 semantic models, some shared across multiple reports
• Refreshes every 30–60 minutes, including near‑real‑time operational data

Here, the team has matured: more models, more viewers, more refreshes. The pain point is concurrency.

On F2, you will likely hit:

• Queued queries when many people open reports at once
• Refresh jobs overlapping and competing with report queries
• Noticeable slowdowns during month‑end or Monday morning peaks

Why F8 is a good default for ~80 viewers

An F8 capacity increases compute, concurrency and memory enough that:

• You can handle dozens of concurrent report queries with acceptable performance.
• Several Import model refreshes can run in parallel without starving interactive queries.
• Direct Lake models benefit from more capacity to serve queries over larger datasets.

For our scenario, on F8 you can typically:

• Keep 10–15 active models in memory without constant eviction.
• Run frequent refreshes (e.g. every 30 minutes) for a handful of operational models.
• Support 80 viewers with 20+ concurrent users at peak without obvious throttling.

Practical setup on F8 for 80 viewers

To make F8 work well:

1. Separate workloads by workspace

   • Put heavy ETL (Dataflows Gen2, notebooks) in a dedicated workspace.
   • Keep high‑traffic reporting workspaces lean and focused on semantic models and reports.

2. Schedule refreshes away from known peaks

   • If everyone opens the same sales report at 09:00, avoid scheduling big refreshes at 08:55–09:05.

3. Use aggregations and incremental refresh where appropriate

   • Reduce the in‑memory footprint and refresh cost for large fact tables.

When F8 isn’t enough

You might need to move beyond F8 if:

• You’re running heavy Spark workloads during business hours.
• You have multiple large Import models (tens of GB each) actively used at peak.
• Peak concurrency regularly exceeds 40–50 active queries.

In those cases, options are:

• Scale up to F16 and keep a single capacity.
• Or, keep F8 and split workloads across two capacities: one for reporting, one for heavy data engineering.

For a typical 80‑viewer reporting scenario without extreme data engineering, F8 is usually the cost/performance sweet spot.

Case 3 – 300 Report Viewers: F64 or Multiple Mid‑Tier Capacities

Profile

• 300 regular viewers across a large department or multiple regions
• 60–100 concurrent users at peak
• 20–30 semantic models, including several large ones
• Frequent refreshes (every 15–30 minutes) for some operational datasets

At this scale, the pain is both concurrency and background workload overlap.

On F8 or F16, you will often see:

• Queued or throttled queries during large peaks (e.g. month‑end closing)
• Refreshes taking longer than expected because they compete with user queries
• Users reporting intermittent slow visuals when many colleagues are online

Why F64 is a realistic choice for 300 viewers

An F64 capacity significantly increases available compute and concurrency. For a large viewer population that mostly consumes reports (not running huge Spark jobs), F64 gives you:

• Enough headroom to serve high concurrent query loads with stable latency.
• Room for several large Import or Direct Lake models to stay hot in memory.
• Capacity to run frequent refreshes and pipelines without crippling interactive usage.

In practice, for our scenario on F64:

• You can support 300 viewers with 60–100 concurrent users during peaks.
• Large models (tens of GB in memory) can be used interactively without constant eviction.
• Multiple refreshes and background jobs can run in parallel, especially if you schedule them sensibly.

Alternative: multiple mid‑tier capacities instead of a single F64

For some teams, splitting into multiple capacities is more cost‑effective and operationally cleaner than a single big F64.

Patterns that work:

• One F32 (or F16/F32 pair) for core reporting and a smaller F8/F16 for data engineering.
• Regional split: one F32 per region if user bases are time‑zone separated and rarely overlap.

Benefits:

• You can isolate noisy workloads (Spark, heavy Dataflows) from critical reporting.
• You can pause smaller capacities outside operating hours to save cost.

Trade‑offs:

• More operational overhead assigning workspaces and monitoring multiple capacities.
• Need clear rules for which workspace goes where.

If your 300 viewers are mostly in one time zone with synchronized peaks, a single F64 for reporting plus a smaller capacity for engineering is often simpler.

How to Avoid Overpaying While Staying Safe

The core risk with Fabric capacities is over‑provisioning “just in case” and then never using the extra headroom. A few practical ways to avoid that:

1. Start Smaller, but Monitor Hard

For each viewer band:

• 10 viewers → start at F2.
• 80 viewers → start at F8.
• 300 viewers → start at F32 or F64, depending on how aggressive your refresh schedule is.

Then rely on:

• Capacity metrics (CPU, memory, query wait times, refresh durations).
• User feedback: slow visuals, refresh delays, timeouts.

If metrics show sustained high utilization and users complain, scale up. If metrics show plenty of idle time, consider scaling down or splitting workloads.

2. Separate Reporting and Heavy Data Engineering

Regardless of capacity size:

• Put ad‑hoc notebooks, large Spark jobs, and heavy Dataflows Gen2 in a dedicated workspace.
• Consider a separate capacity for those if they run during business hours.

This avoids a single big ETL job degrading report performance for hundreds of viewers.

3. Use Scheduling and Model Design Before Scaling

Before you add more capacity:

• Stagger refreshes away from known peaks.
• Use incremental refresh for large Import models.
• Consider aggregations for high‑volume fact tables.

These reduce memory and compute pressure and often postpone the need for a bigger SKU.

4. Pause When You Can

If you have capacities dedicated to:

• Development / test
• Regional workloads with strict business hours

Use capacity pause features to stop them outside operating hours. This can materially reduce cost without impacting users.

One Practical Takeaway

When you’re choosing between F2, F8 or F64, don’t start from a SKU table; start from peak concurrent viewers plus refresh overlap. For roughly 10, 80 and 300 report viewers, F2, F8 and F64 are sensible defaults, but only if you monitor capacity, separate noisy workloads, and fix model design before you reach for a bigger bill.