Subscribe
Share
Share
Embed
Fabric doesn't charge you when work happens — it spreads the cost forward into 2,880 thirty-second timepoints. That one sentence explains every confusing capacity behavior, including why surge protection can reject the SQL it's supposed to protect.
Episode 37 • 2026-10-16 Duration: 9:21
Fabric doesn't charge you when work happens — it spreads the cost forward into 2,880 thirty-second timepoints. That one sentence explains every confusing capacity behavior, including why surge protection can reject the SQL it's supposed to protect.
The Fabric Friday video on this topic: https://youtu.be/iE-jdcseCaY
AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.
Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.
Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.
This podcast was generated by AI. Both voices are synthetic: Matthias is a cloned voice, Fabia is a designed AI co-host.
Brand design based on fabricperiodictable.com.
Architecture decisions for Microsoft Fabric. Anonymized real customer scenarios, cost realism, counter-arguments included. Weekly episodes aligned with Fabric Friday recordings.
Throttled by Yesterday's Refresh
Episode 37 | 2026-10-16
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: Three in the afternoon. Users say Fabric is slow. By four, they say it's down. The admin checks the Metrics app — nothing is running.
[00:16] Matthias: No pipeline, no refresh?
[00:18] Fabia: The culprit finished twelve hours ago.
[00:21] Matthias: That's not how anyone thinks about compute.
[00:24] Fabia: Fabric doesn't work that way. It spreads the cost forward — interactive work over five to sixty-four minutes, background work over twenty-four hours. That one sentence explains every confusing capacity behavior.
[00:38] Matthias: So we're pulling apart what that forward-spreading actually does to you.
[00:43] Fabia: The unit nobody talks about is the timepoint. Thirty seconds long. A day holds two thousand eight hundred and eighty of them. Every operation you run drops a slice of its cost into a set of those slots.
[00:56] Matthias: So each slot has a budget tied to the SKU.
[00:59] Fabia: An F2 gets sixty CU seconds per timepoint. And smoothing decides how many slots your operation pays into.
[01:06] Matthias: So a big background job doesn't hit one slot hard. It's... divided across all two thousand eight hundred and eighty.
[01:14] Fabia: The docs walk through it. One background job on an F2 consuming one CU hour — three thousand six hundred CU seconds. Each timepoint gets one point two five. About two percent of that slot's budget.
[01:27] Matthias: Two percent. From a job that used six times what the next ten minutes could hold.
[01:32] Fabia: And it throttled nothing. That's what smoothing buys — you size on the average.
[01:38] Matthias: Does the job itself run slower because of the smoothing?
[01:41] Fabia: No. The documentation is explicit — smoothing won't affect execution time. The job runs at full speed. What changes is when the cost is counted.
[01:51] Matthias: It's accounting. Good accounting, but accounting.
[01:54] Fabia: A cost feature before it's anything else.
[01:57] Fabia: In the video, you can see this play out. One heavy notebook finished hours earlier, still paying into evening timepoints. Seven point seven five CU seconds charged to a single slot out of over twenty-two thousand total.
[02:11] Matthias: And if you divide by two thousand eight hundred and eighty?
[02:15] Fabia: You land exactly on that number. Smoothing is a division.
[02:19] Matthias: Okay, so who decides whether something gets the five-minute window or the twenty-four-hour window? Can I choose?
[02:27] Fabia: You can't. Classification happens before the operation runs. Every operation stops at a gate, gets stamped interactive or background, and only then starts.
[02:37] Matthias: What if it's ambiguous?
[02:39] Fabia: Falls back to background. The documentation says that's in your best interest — twenty-four-hour smoothing means a smaller share per slot.
[02:48] Matthias: So the default is the gentle option. That's... reassuring.
[02:52] Fabia: For throttling, yes. Keep that in your pocket.
[02:55] Fabia: Throttling itself is a staircase. Three stages, keyed to how many minutes of future capacity you've already spent. Under ten minutes, nothing happens — that's overage protection. Past ten, new interactive operations wait twenty seconds.
[03:11] Matthias: Background?
[03:11] Fabia: Unaffected at stage one. Past sixty minutes, interactive operations are rejected outright. Background jobs can still start and run. Past twenty-four hours, everything new is rejected.
[03:24] Matthias: Wait — at stage two, the dashboard is down but the pipeline behind it keeps running? And keeps adding to the debt?
[03:31] Fabia: By design.
[03:32] Matthias: That's a team watching their reports go dark while the thing causing it—
[03:37] Fabia: —keeps running, yes. And two workloads skip steps entirely. Real-Time Intelligence skips the twenty-second delay because that would defeat the purpose. It runs full speed until rejection at sixty minutes.
[03:50] Matthias: And eventstreams?
[03:51] Fabia: Their operations can run for years, so throttling new ones doesn't make sense. Instead, Fabric reduces the CU allocated to keeping the stream open. No error. It just falls behind.
[04:03] Matthias: The quietest failure mode for the workload you'd notice last.
[04:07] Fabia: Someone posted about exactly this pattern. Their words: "We got throttled at 3pm. Nothing was running at 3pm. What happened?"
[04:16] Matthias: And now that answer writes itself.
[04:19] Fabia: The refresh that finished last night deposits a slice into every one of the next two thousand eight hundred and eighty timepoints. At 3pm, you're still paying for it. The suspect list in the Metrics app is a day long.
[04:33] Matthias: So you don't hunt for the 3pm culprit. You read the ledger.
[04:37] Fabia: The timepoint page lists every background operation that completed within the last twenty-four hours. That's the list.
[04:45] Matthias: Now I want to come back to that classification stamp. You said keep it in my pocket.
[04:50] Fabia: Here's where it turns. Fabric classifies almost all Warehouse operations as background. Deliberately. Your query peaks don't trigger throttling because they're spread over twenty-four hours.
[05:03] Matthias: That's the favor.
[05:04] Fabia: Now turn on surge protection. It rejects background jobs to protect interactive work. And the docs say it directly — many interactive operations like SQL queries are also considered background and might be rejected.
[05:19] Matthias: So the stamp that shields my SQL from throttling is the same stamp that gets it killed by surge protection.
[05:26] Fabia: One fact. Two opposite consequences.
[05:28] Matthias: Then who is surge protection actually for?
[05:31] Fabia: Capacities where Power BI reports share space with Spark pipelines. The report is interactive, the pipeline is background — surge protection makes sense there.
[05:42] Matthias: But if my critical path is SQL — and that describes a lot of analytics workloads — surge protection is actively working against me. For that case, the docs say dedicated capacity. And they're right, but that's a harder conversation with the budget.
[05:58] Fabia: The documentation doesn't call it a sizing fix. It says it's not a substitute for proper capacity sizing.
[06:05] Matthias: So let me think about the teams who want to scale down at night. The pitch is always the same — drop to a smaller SKU, save half the bill.
[06:14] Fabia: The arithmetic is clean but not kind. Halving the SKU doubles the percentage. The documented example: F128 should sit below forty percent smoothed to land at eighty percent on F64.
[06:26] Matthias: What if I'm at fifty?
[06:28] Fabia: A hundred percent on F64. No headroom. The next spike eats the ten minutes of overage protection and you're at stage one.
[06:36] Matthias: The comfortable fifty flips to—
[06:38] Fabia: —an emergency, yes. And the trap inside that trap: the night you want to scale down in is still carrying yesterday's daytime work. Background smoothing is twenty-four hours. There's a quiet period in the calendar. There isn't one in the accounting.
[06:55] Matthias: That's the sentence I'd put on a slide and leave up for the rest of the meeting.
[07:00] Matthias: Okay, but let me push the other way. Autoscale billing for Spark — that's a completely different model.
[07:07] Fabia: It turns smoothing and bursting off for Spark entirely. Pay-as-you-go. Interactive Spark jobs get throttled when CUs are used up. Background Spark jobs are queued — up to two thousand forty-eight if that's your CU limit.
[07:22] Matthias: So you give up the predictable bill.
[07:24] Fabia: And you get a predictable absence of self-inflicted throttling.
[07:28] Matthias: For a team running heavy Spark and getting burned by the smoothing window, I'd look at that seriously. The fixed bill only helps if the capacity is sized right, and I keep running into teams that are undersized for what they're actually doing.
[07:45] Fabia: Which is the documented point — it trades one kind of predictability for another. The question is which surprise you'd rather not have.
[07:54] Matthias: The thing I'd genuinely lose sleep over is the surge protection misunderstanding. A team turns it on, believes their SQL is protected, and the first background spike gets those queries rejected.
[08:07] Fabia: And the rejection doesn't say "classified as background." It just fails, and they go hunting for what's wrong with the query.
[08:15] Matthias: The risk I'd accept? Sizing one SKU step larger than the math says. That costs money. An outage costs more.
[08:22] Fabia: Show me the query pattern — but for capacity, show me the smoothed line. That's the only line that predicts anything.
[08:30] Matthias: The whole lesson is one sentence: capacity is an accounting system with a twenty-four-hour delay built into it. Once you know the delay, the Metrics app stops being a mystery and starts being a ledger.
[08:44] Fabia: Right now, somewhere, there's a capacity chart with a quiet-looking evening. Every timepoint between now and tomorrow morning is still filling up from today.
[08:55] Matthias: And someone's about to halve the SKU because the chart looks calm.
[08:59] Fabia: The spike they see is a receipt. The smoothed line is the bill that hasn't arrived.
[09:05] Matthias: If this changes how you size your capacity, DM me on LinkedIn — find me as Matthias Falland.
[09:11] Fabia: See you next Friday.
---
End of episode. ~09:12 estimated.