images/blogs/Newsletter_Issue_4.png#joomlaImage://local-images/blogs/Newsletter_Issue_4.png?width=1279&height=720

May 29, 2026

Friday Fabric Facts #4: The "Infinite Capacity" Trap: Why Your Fabric Bill Might Explode (And How to Smooth It Out)

In the cloud era, we traded "provisioning servers" for "provisioning capacity." The promise was simple: Pay for what you use, scale when you need it.

But with Microsoft Fabric, the economic model has shifted again, and most leaders haven't adjusted their strategy. We moved from paying for storage (the data lake era) to paying for compute intensity (the Fabric era).

The danger? The "Infinite Capacity" Trap.

Fabric allows your workloads to "burst" beyond your purchased capacity to handle spikes. This feels like magic- until the bill arrives, or worse, until your entire tenant gets throttled because you borrowed too much from the future.

If you are treating Fabric capacity like a static server (buy it and forget it), you are already losing money. Capacity is now a financial instrument. You need to manage "smoothing" and "throttling" the same way a CFO manages cash flow.

Today, I’m breaking down the economics of Fabric capacity and why "smoothing" is the most misunderstood competitive advantage for SMBs.

The Professional Reality: The "Monday Morning Crash"

I recently advised a FinTech scale-up ($80M ARR) that migrated from Power BI Premium to a Fabric F64 capacity.

Their team loved the speed. They scheduled every heavy ETL job, every model refresh, and every data warehouse load to run at 8:00 AM Monday morning, right before the executive meeting.

For three weeks, it was perfect. Then, on Week 4, everything froze.

Reports didn't load. Pipelines failed. The CTO got an alert: "Capacity Throttled."

The Root Cause: They hadn't run out of money. They had run out of "Smoothing Credits." By stacking every job at 8:00 AM, they spiked their usage to 400% of their F64 limit. Fabric's "Bursting" feature allowed this... for a while. It smoothed that spike over 24 hours. But eventually, the debt came due. They had borrowed so much compute from the future that Microsoft locked the doors until the debt was paid.

They didn't need a bigger server (an F128 would cost $30k more/year). They needed a better schedule.

This is the new reality: Architecture is no longer just about code. It’s about timing.

The Strategic Shift: Managing "Compute Debt"

Microsoft Fabric introduces a concept called "Smoothing." Instead of capping you instantly when you hit 100% usage, Fabric averages your consumption over a rolling 24-hour window.

Think of it like a credit card:

You can spend $10,000 today (Bursting), even if your daily limit is $1,000.
BUT, you have to pay it back over the next few days.
If you keep spending, your card gets declined (Throttling).

The Strategy for SMBs: Stop building for "Peak Load." Build for "Average Load."

In the old world (SQL Server), you had to buy a server big enough for your busiest hour. If you needed 64 cores for 1 hour a day, you paid for 64 cores for 24 hours. Wasteful.

In the Fabric world, you can buy a smaller capacity (F32) and let "Smoothing" handle the 8:00 AM spike, IF you ensure the rest of the day is quiet enough to pay back the debt.

This is the arbitrage opportunity: Smart architects can run massive enterprise workloads on SMB-sized capacities by optimizing for time, not just performance.

✅ The Move (Proof of Execution)

Strategy is useless without visibility. You cannot manage what you do not measure. Here is how we took control of that FinTech's capacity in 48 hours.

1. Install the "Fabric Capacity Metrics App" (The CFO’s Dashboard)

This isn't just a technical log; it's your balance sheet.
We installed the app and looked at the "Timepoint"

2. Identify the "Whales"

We filtered by Background % vs Interactive %.
We found one specific Gen2 Dataflow that was consuming 60% of their daily credit in 30 minutes. It was doing a full load of a 50GB table instead of an incremental refresh.

3. Flatten the Curve (The Fix)

Action: We shifted that massive Dataflow to run at 3:00 AM (the "valley" of usage).
Action: We enabled "Incremental Refresh" so it only processed new rows.
Result: The 8:00 AM spike dropped by 70%. Their "Smoothing Debt" vanished. They stayed on the F64 capacity instead of upgrading, saving $30,000/year.

Newsletter Issue 4 Image 01

The "Gotcha" That No One Discusses

Here is the trap: Interactive Bursting works differently.

Fabric treats User Actions (clicking a report) differently than Background Jobs (ETL pipeline).

Background Jobs are smoothed over 24 hours.
Interactive Actions are smoothed over just 5 minutes.

Why this matters: You can overload your capacity with background ETL jobs, and your users won't feel it immediately. But if 500 users log in at once and hit a complex dashboard? That spike hits now.

My Thinking Framework: Always leave a "Headroom Buffer" for interactive users. If your background ETL is consistently eating 90% of your capacity, your CEO's dashboard will be slow, regardless of smoothing.

True expertise is preserving the user experience. We protect the "Interactive" lane at all costs.

A Note to My Partners & Peers

As we move deeper into the Fabric era, our role as partners is shifting from Technical Implementation to Economic Optimization.

Clients don't just want us to build pipelines. They want us to manage their cloud unit economics.

If you are a Microsoft Partner, MSP, or IT Leader struggling to predict or control your Fabric spend, this is where I operate. I help organizations design architectures that are not just technically sound, but financially optimized.

We don't just solve "Will it run?" We solve "Should we pay for it?"

Let’s elevate the conversation.