Synapse versus Fabric on cost.

Microsoft is steering new analytics work toward Fabric, but the cost question is concrete, not directional. Here is how to reason about it.

How does Azure Synapse bill?

Synapse is a collection of engines, each metered on its own model.

Dedicated SQL pool is provisioned capacity measured in data warehouse units. You pay for the size you provision while it is online, and crucially you can pause it, which stops the compute charge and leaves only storage. For a warehouse that runs on a predictable schedule, pausing is a powerful lever.

Serverless SQL pool bills per terabyte of data processed by each query, with no capacity to manage. It suits ad hoc querying over data in the lake, and its cost scales directly with how much data your queries scan, which makes file layout and pruning the main cost control.

Apache Spark pools bill by vCore hour with configurable auto pause, so idle clusters stop costing money. Storage in the attached data lake is billed separately.

The Synapse pattern, then, is granular: you pay per engine, and your savings come from pausing what you can and scanning less where you cannot.

How does Microsoft Fabric bill?

Fabric flips the model. You buy one capacity, an F SKU sized in capacity units, and every Fabric workload in that tenant or workspace draws compute from it. There is no separate meter per engine; there is one pool and a budget of capacity units per second.

Three behaviours shape the cost. Smoothing spreads bursty demand over time so a short spike does not require a permanently larger capacity. Bursting lets a job temporarily use more than the steady rate, borrowing against future smoothing. Throttling is what happens when sustained demand exceeds the capacity: jobs slow or queue rather than auto billing more. You can also pause an F capacity to stop the compute charge entirely, and you can buy a one year reservation on capacity for a meaningful discount over pay as you go (indicative, confirm on the current pricing page). OneLake storage is billed on top.

The Fabric pattern is the opposite of Synapse: you pay for one capacity whether one workload uses it or ten, so the cost per workload falls as you consolidate and rises if the capacity sits half idle.

Which is cheaper for your workload?

The honest answer is that it depends on shape and consolidation, not on a list price.

The deciding question is utilization. A Fabric capacity that runs busy across many workloads is efficient; one bought for a single intermittent job is expensive. Size it to real demand, use smoothing rather than overprovisioning for peaks, and pause or reserve where the pattern is predictable.

A worked example: consolidation versus an idle capacity

How should you decide and migrate?

Start from utilization, not the roadmap. Measure how busy each Synapse engine actually is, model a Fabric capacity sized to smoothed demand for the workloads that genuinely share a pattern, and keep isolated, intermittent jobs where the per use meter is cheaper. Where you do move to Fabric, buy a reservation only on the steady baseline and pause capacity on predictable idle windows, the same commitment logic as the risk adjusted approach to Azure commitments. Watch the storage side too, covered in snapshot and backup cost discipline. The full data platform picture sits in the Azure cost optimization guide.

Get the buyer side analytics cost playbook

We model Synapse and Fabric against your real utilization, not a vendor roadmap, and recommend the cheaper path with zero provider commissions. It is the same discipline behind the 31 percent median reduction we see in the first 90 days. Our guarantee: we reduce your cloud spend or we reimburse our service fee.