Synapse, Fabric and Data Factory pricing

Microsoft Fabric pricing is capacity units per hour: a capacity of SKU F2 to F2048 carries as many CUs as its name says, pays them every hour it runs whether queries run or not, and every workload from Power BI through Spark to the data warehouse draws from the same pool; on top come OneLake storage per GB and month, which consumes no CUs, and the overage a capacity may consume beyond its limit when it is switched on. Azure Synapse Analytics charges per component instead, data warehouse units per hour for the dedicated SQL pool, terabytes per query for the serverless one, vCore-hours for Spark, and Azure Data Factory counts activity runs, DIU-hours for copying and vCore-hours for data flows. On the bill, Fabric is dominated by the capacity that runs around the clock, Synapse by the dedicated pool that was not paused, and Data Factory by the data flows with their minimum cluster.

Pricing dimensions

The three services are three pricing models for similar work: Fabric sells a capacity, Synapse components, Data Factory operations. Every item has its own meter, and on Fabric the SKU sets the number of units.

Fabric inverts the Synapse logic: not the work is metered but the capacity that absorbs it, and the work is smoothed in CU-seconds onto that capacity, interactive operations over at least five and up to 64 minutes, background operations such as refreshes and Spark jobs over 24 hours. A capacity can briefly consume more than it has, and the overage is carried forward into the next timepoints; once the next ten minutes are full, throttling begins, first with delays on interactive operations, then with rejections. A pause ends throttling at once and stops billing; the carried-forward overage is summed and charged on pausing. Switched-on overage replaces throttling with payment: the excess consumption is charged at its own rate per CU-hour, on reserved capacities too at the pay-as-you-go reference. OneLake storage is charged per GB and month and consumes no CUs; the read and write transactions on it are categorised as on Azure Data Lake Storage and booked in CUs. What a capacity costs a team therefore hangs on two decisions, the SKU and the running time, not on the number of queries; the mechanics across all three providers are in data warehouses and analytics.

Synapse charges per component: the dedicated SQL pool costs per 100 DWU and hour from start to pause and its storage per TB and month while paused too, the serverless pool per TB of data processed per query, Spark pools per vCore-hour while they run, and the pipelines as Data Factory. Data Factory counts three things: activity runs per 1,000, with triggers and debug runs, data movement per DIU-hour, where the service picks the data integration units per copy activity and the hour counts by the minute, and data flows per vCore-hour of a Spark cluster of at least eight vCores, whose time to live keeps paying after the run. Databricks on Azure is a second bill: the DBUs per hour by workload on the Premium tier and the cluster's virtual machines at their own rates, both per second as long as the cluster runs.

How it appears in your billing data

In the cost export, Fabric carries the ServiceName or MeterCategory Microsoft Fabric with the subcategories Fabric Capacity and OneLake; the MeterName names the workload and the kind, Spark Memory Optimized Capacity Usage CU, Power BI Capacity Usage CU, Dataflows Standard Compute Capacity Usage CU, Capacity Overage Capacity Usage CU for the overage, OneLake Storage Hot Data Stored per GB and month, and the unit is the CU-hour, spread over the workloads that consumed the capacity. The ResourceId is the capacity (microsoft.fabric/capacities), not the workspace; attribution per workspace, item and user comes only from the Fabric Capacity Metrics app, not from the export. Synapse sits under Azure Synapse Analytics with the subcategories Dedicated SQL Pool (100 DWUs per hour with the level name such as DW1000c as the MeterName), Serverless SQL Pool (Standard Data Processed per TB), Serverless Apache Spark Pool - Memory Optimized (vCore per hour), Pipelines (Azure Hosted IR Orchestration Activity Run, Azure Hosted IR Data Movement, Azure Hosted IR Pipeline Activity) and SQL Storage (Standard LRS Data Stored per TB and month); the ResourceId is the pool or the workspace.

Data Factory sits under Azure Data Factory v2 with the subcategory per integration runtime, Cloud, Self Hosted or Azure Managed VNET, and the MeterName per operation: Cloud Orchestration Activity Run per 1,000, Cloud Data Movement per DIU-hour, Cloud Pipeline Activity and Cloud External Pipeline Activity per hour, Inactive Pipeline per month, Cloud Read Write Operations and Cloud Monitoring Operations per 50,000; data flows under Azure Data Factory v2 Data Flow - General Purpose and the other compute types with vCore per hour. The ResourceId is the factory; attribution per pipeline comes from the factory's monitoring view with the consumption per activity run, and on data flows with time to live the vCore-hours sit with the integration runtime, not with the pipeline. Databricks appears twice: the DBUs under Azure Databricks with the SKU as the subcategory, Premium All-purpose Compute, Premium Jobs Compute, Premium Serverless SQL, and the cluster VMs under Virtual Machines in the workspace's managed resource group, with the cluster tags Databricks sets. Which fields the export carries is described on the page on Azure cost exports; in the FOCUS export the Fabric reservation is PricingCategory Committed and the pay-as-you-go capacity Standard, x_SkuMeterName carries the meter name (FOCUS columns).

Levers

Configuration: on Fabric the running time is the first lever, because the capacity pays per hour and the pause ends it; a development capacity paused at night and at the weekend pays a third. The second is the SKU, because the price goes linearly with the CUs and smoothing over 24 hours lets a small capacity carry background load a large one would be needed for only at peaks; the Capacity Metrics app shows the utilisation per timepoint. The third is F64 as the licence boundary: below F64 every viewer of Power BI content needs a Pro licence, from F64 not, which with many viewers pays for the larger SKU. On Synapse the pause of the dedicated pool is the lever, with storage as the remainder; on Data Factory the cluster size and the time to live of the data flows and the bundling of activities, because every run counts.

Purchase option: a Fabric reservation over one or three years lowers the CU-hour by about 41 percent but pays every hour, paused ones included; it pays off for capacities that run around the clock, and not for those that pause, because the pay-as-you-go price of half the running time is below the reservation price of all of it. For dedicated SQL pools there are reservations, for data flows reserved instances; what such a commitment carries is in reserved capacity for managed services.

Architecture: Fabric for teams that bundle Power BI, lakehouse and warehouse on one capacity and whose load spreads over the day; Synapse dedicated pools only with a pause schedule; data flows only where Spark transformations are needed, and copy activities with limited DIUs for the rest. One capacity per environment instead of per team keeps the number of hours small; the separation per team a chargeback needs comes from the Metrics app, not from a second capacity. How shared capacities are spread is described in shared cost.

Where it goes wrong

• The capacity runs at the weekend. An F64 pays 168 hours a week, with or without queries. A schedule that pauses the development and test capacities is the first measure; the pause ends billing at once.
• The reservation pays for the pause. A reserved capacity costs every hour, paused or not. Reserve what runs around the clock, pay-as-you-go for the rest.
• Overage is on and unlimited. The overage is checked against the limit every five minutes and can exceed it; without a limit a background load pays any number of CU-hours at the overage rate.
• The dedicated pool was never paused. A DW1000c pays its hours without queries too; 100 DWUs per hour without Standard Data Processed beside it is the clue. A schedule through the pipelines pauses it after the load.
• Every file an activity run. A pipeline with ForEach over 10,000 files pays 10,000 activity runs per run. One copy over a pattern instead of per file lowers the runs to one.
• The data flow cluster stays warm. A time to live of an hour pays eight vCores per hour after every run. Short time to live for rare runs, long only for pipelines with many flows in sequence.
• The bill knows no team. Fabric lines carry the capacity, not the workspace; the Metrics app delivers the spread per item and user, the export does not. The chargeback needs both.

Example

List prices from the Azure Retail Prices API in EUR for Germany West Central, read on 2026-10-21: Fabric capacity costs EUR 0.1936 per CU and hour at pay-as-you-go, the reservation EUR 1,008.4477 per CU for one year and EUR 3,025.3432 per CU for three years, the overage EUR 0.5808 per CU-hour; OneLake storage EUR 0.0211 per GB and month hot, EUR 0.0115 cool, EUR 0.0044 cold. The dedicated SQL pool costs EUR 1.3288 per 100 DWU and hour, so EUR 13.2876 for DW1000c, its storage EUR 20.2394 per TB and month; the serverless pool EUR 4.3999 per TB; a Spark pool EUR 0.1324 per vCore-hour. Data Factory costs EUR 0.88 per 1,000 activity runs on the Azure integration runtime and EUR 1.32 on the self-hosted one, EUR 0.22 per DIU-hour, EUR 0.0044 per hour of pipeline activity, EUR 0.2345 per vCore-hour of data flow general purpose and EUR 0.704 per inactive pipeline and month; Databricks EUR 0.484 per DBU-hour all-purpose and EUR 0.264 per DBU-hour jobs on the Premium tier, without the VMs.

An F64 that runs the whole month costs 64 × 730 × 0.1936 = EUR 9,044.99; reserved for a year 64 × 1,008.4477 / 12 = EUR 5,378.39 a month, about 41 percent less; at pay-as-you-go with a pause from 19:00 to 07:00 and at the weekend, so 260 hours a month, 64 × 260 × 0.1936 = EUR 3,221.50, less than the reservation, because half the running time beats the discount. An F16 for the same background load, which smoothed over 24 hours fits into 16 CUs, costs EUR 2,261.25 around the clock, and 10 TB of hot OneLake storage EUR 216.06 a month. A DW1000c that runs 10 hours on 22 working days costs 220 × 13.2876 = EUR 2,923.27 plus 20 TB of storage EUR 404.79; the same pool without a pause EUR 9,699.95. A Data Factory pipeline that copies 1 TB a day with 30 activity runs and 380 DIU-hours a month, Microsoft's own worked example, costs EUR 0.03 plus EUR 83.60; a data flow with eight vCores that runs two hours a day 8 × 2 × 30 × 0.2345 = EUR 112.56, and a time to live of an hour after every run adds EUR 56.28. The figures show that running time sets the price on Fabric and Synapse, that a pause beats the reservation as soon as the capacity runs less than about 59 percent of the time, and that on Data Factory the data flows, not the runs, carry the line.

Sources

Read on 2026-10-21. Prices: Azure Retail Prices API, EUR, Germany West Central, queries Microsoft Fabric, Azure Synapse Analytics, Azure Data Factory v2 and Azure Databricks; Microsoft Fabric pricing, Azure Synapse Analytics pricing, Azure Data Factory pricing, Azure Databricks pricing. Service: Microsoft Fabric licenses, pause and resume your Fabric capacity, throttling and smoothing, OneLake consumption, Azure Data Factory pricing examples. Billing data: cost details fields, FOCUS schema of the cost export.