What "You Own the Runtime" Actually Means When Fabric Throttles Your Capacity

Microsoft Fabric capacity throttling is the loudest recurring complaint in data engineering right now. Threads about 3x overage charges and capacity smoothing that punishes a spike show up weekly. Here's the honest part: BimlFlex doesn't fix that. No automation tool fixes Microsoft's pricing model. We checked our own codebase before writing this, and there's no capacity logic, no overage handling, no throttling workaround anywhere in it. Sizing your Fabric capacity is between you and Microsoft.

‍

What metadata-driven generation changes is everything around that capacity: who holds the audit trail when a workload runs, and whether a pipeline that dies mid-load under throttling can pick up where it stopped instead of starting over. That's what "you own the runtime" means in practice, and it pays to be precise about it.

‍

Start with where the work runs. BimlFlex generates native pipelines for your target. For an ADF or Fabric target, what you receive is an actual ADF or Fabric pipeline definition that lands in your workspace and executes on your capacity. The operational repository that records every run, BimlCatalog, is a database project you deploy into your own database. It compiles to a DACPAC and publishes to a server you name, with the authentication you control. In 2026 that target can be PostgreSQL as well as SQL Server. There's no Varigence service in the data path, and nothing to phone home to. When your capacity throttles, no third party is sitting between you and your own audit trail.

‍

That audit trail is the reason throttling becomes survivable rather than mysterious. Every execution writes a row you can read. In your own BimlCatalog, the bfx.Execution table looks like this:

‍

CREATE TABLE [bfx].[Execution]( 

[ExecutionID] BIGINT IDENTITY (1,1) NOT NULL, 

[ParentExecutionID] BIGINT NULL, 

[ExecutionStatus] CHAR(1) NULL, 

[NextLoadStatus] CHAR(1) NULL, 

[StartTime] DATETIMEOFFSET(7) DEFAULT (GETUTCDATE()) NULL, 

[EndTime] DATETIMEOFFSET(7) NULL, 

[Duration] AS (DATEDIFF(SECOND,[StartTime],[EndTime])) PERSISTED, 

... 

‍

Duration is a persisted computed column, and a sibling table records rows moved per component (bfx.RowCount). Put those together and you can answer the question throttled teams actually ask: which batch consumed the window, how long it ran, how many rows it pushed, and whether that's creeping up over time. The data to correlate a workload against a capacity bill is already in your database. Lineage and audit reporting work the same way, generated rather than reconstructed after the fact.

‍

Then there's recovery, which is where throttling does real damage. When a batch gets cut off partway, you don't want the next run reprocessing everything from zero on the same constrained capacity. BimlCatalog tracks what the next run should do per package in the NextLoadStatus column, with P for process, C for skip, R for rerun, and D for resume. On a failure, you see the row in your own bfx.Execution table updated to record it:

‍

UPDATE [bfx].[Execution] 

SET [ExecutionStatus] = 'F', 

[NextLoadStatus] = CASE WHEN @SkipCopyOnRestart = 1 THEN 'D' ELSE 'R' END, 

[EndTime] = @ExecutionEndTime 

WHERE [ExecutionID] = @ExecutionID 

‍

The next run reads that status and branches: R retries the failed package, D resumes a Databricks job whose copy steps already succeeded so they aren't repeated. On a clean finish the status resets to P and the batch's children reset with it. The same behavior holds whether you deploy your catalog to SQL Server or PostgreSQL. All of it runs inside your database. The decision about whether to resume or restart is made by a stored procedure you own, not a service you rent.

‍

So the honest shape of it is two sentences. BimlFlex doesn't make Fabric capacity cheaper or smoother. It makes the workload on that capacity observable, restartable, and entirely yours, so a throttling event is a row in your audit log and a clean resume, not an outage and a full reload.

‍

That's the practical edge of owning the code. The pipeline runs where you run it. The audit trail lives where you keep it. When the contract ends or the capacity tightens, nothing you depend on is somewhere else.