Microsoft Fabric

Fabric feeling slow? Ask these questions before you upgrade.

An upgrade is a decision, not a diagnosis. Start with the workload evidence and make the next conversation with your data team more useful.

September 23, 20264 min readGuildBuild Team

Microsoft FabricCapacity optimizationFinOps

In this article

Is capacity actually the bottleneck?

A slow report can have several causes. The model may be inefficient, a source may be slow, or workloads may be competing for compute. Increasing capacity before identifying the bottleneck can leave the underlying problem in place.

Microsoft recommends using the Fabric Capacity Metrics app to understand utilization and investigate high-consuming items and operations. Treat the observation window as part of the evidence: one unusually busy period may not represent a normal month.

What happened when people felt the slowdown?

Ask your team to line up user-reported times with the capacity evidence. Fabric distinguishes interactive operations, such as report queries, from background operations, such as refreshes. Its smoothing behavior means consumption and user experience need to be interpreted together.

A useful report identifies the affected workload, the time window, the observed pressure, and what remains unknown. “The platform is slow” is a symptom; it is not yet a diagnosis.

Which options are worth testing?

For an illustrative planning discussion, compare three options: tune a costly workload, change when background work runs, or change available capacity. Each option has a different operational tradeoff. Rescheduling is less useful if a report needs data at a fixed time; tuning needs someone who can maintain the result.

Write down the assumption behind each option and the check that would confirm it. Avoid a promised savings percentage before you have a representative baseline and an agreed way to measure the change.

Figure 01Decision guide

Match the proposed fix to the evidence

Costly report

What the team seesOne report query repeatedly takes longer than comparable requests.

What to test nextTune the query or model and retest the same report interactions.

Overlapping workloads

What the team seesSlow report interactions coincide with expensive refreshes.

What to test nextMove a refresh and check responsiveness while preserving the data freshness requirement.

Sustained pressure

What the team seesThrottling persists across ordinary busy periods after workload fixes.

What to test nextTrial more capacity with the same workload and compare throttling, response time, and cost.

Illustrative diagnostic choices. A matching time window helps narrow the cause. Test the proposed change against a representative baseline.

Make the budget conversation concrete

Bring a short decision note: what users experienced, what the telemetry shows, which intervention you propose, and how you will compare the result. Keep licence and capacity pricing current, and confirm the applicable terms separately.

GuildBuild’s Fabric capacity reference approach is built around read-only diagnosis and plain-language evidence. Explore performance and cost optimization to discuss your workload.