The Problem Scenario Currently, Microsoft Fabric evaluates capacity utilization based strictly on a 24-hour moving average for background operations and a 5-minute window for interactive operations. While this smoothing mechanism manages minor daily spikes, it completely ignores long-term underutilization history. Consider this realistic enterprise scenario: An organization purchases a premium F64 capacity. For 29 days of the month, the capacity runs at a quiet 3% to 5% utilization. The customer is consistently paying for premium hardware performance that sits completely idle, yielding massive resource margins back to the cloud infrastructure. On day 30, the team needs to execute a massive, critical end-of-month data processing job or a full historical reload. The workload causes an instant utilization spike of 10,000%. Even when smoothed over a 24-hour window, this massive burst triggers aggressive throttling, freezing new requests and grinding business operations to a halt. Fabric's architecture treats this customer exactly the same as a user who has been redlining their capacity to the absolute limit for the past week. The system has zero memory of the 29 days of idle capacity that the customer fully paid for. Why the Current Model Feels Broken for Businesses From a budgetary and finance perspective, cloud capacities are viewed as an allocated pool of paid resources. When an enterprise pays for continuous premium capacity but faces severe performance penalties the moment they actually need to harness that power, it creates a "use-it-or-lose-it" paradox. It penalizes customers for having irregular or batch-heavy data lifecycles despite their significant financial commitment. Proposed Solutions / Feature Requests I request that Microsoft introduce a more flexible, financially empathetic mechanism to handle historical underutilization for dedicated F-Capacities: Historical "Capacity Banking" (Rollover CUs): Allow capacities that consistently run below a specific threshold (e.g., under 15% utilization for more than 7 consecutive days) to accumulate a "Burst Credit Buffer." If a sudden massive job is triggered, let the system draw down from this historical bank to offset the 24-hour smoothing debt before triggering harsh throttling. Idle-Time Autoscale Credits: Instead of requiring customers to pay additional out-of-pocket costs for Azure Autoscaling during a critical spike, allow historical idle time to act as a credit pool to fund temporary, automatic scale-ups (e.g., automatically bumping from F64 to F128 using accumulated credits). Configurable Smoothing Windows for Premium Tiers: Give Fabric Administrators the option to extend the background job smoothing window from 24 hours to 7 days for higher capacity tiers, allowing large monthly or bi-weekly batch loads to naturally dilute over a wider historical window.
... View more