Microsoft Fabric Pricing: Capacity Units, F-SKUs, and What You Pay

Microsoft Fabric pricing has two parts that teams routinely blur together, and getting them straight is the whole game. You buy a capacity, which is a pool of compute measured in Capacity Units and sold as an F-SKU, and you buy per-user licenses for the people who create and view content. On top of both, OneLake storage is billed separately by volume. Miss any of the three and your estimate will be wrong.

This guide breaks down each component with illustrative scenarios so you can estimate what you will actually spend. Unless stated otherwise, prices are US dollar list prices for the East US region, taken from the Azure Retail Prices API on 16 October 2026, with a month counted as 730 hours. Prices change and vary by region, so always verify against the official Microsoft Fabric pricing page before you budget.

How Fabric Pricing Works: The Capacity Model

Fabric runs all its workloads, data engineering, warehousing, real-time analytics, data science, and Power BI, on a shared compute pool called a capacity. You do not pay per query or per pipeline run. You pay for the capacity itself, sized by an F-SKU, and every workload draws from that same pool. This is convenient (one bill for everything) and also the source of most cost confusion, because a single number has to cover wildly different workloads.

There are three cost components. The capacity (F-SKU) is usually the largest line and is fixed for the size you choose. Per-user licenses (Free, Pro, or Premium Per User) determine who can create and view content, and below a certain capacity size they are mandatory for every viewer. OneLake storage bills separately by the terabyte. The capacity is the anchor; the other two scale with your people and your data.

F-SKUs and Capacity Units

Compute is measured in Capacity Units (CUs), and F-SKUs are sold in a doubling ladder: F2 has 2 CUs, F4 has 4, and so on through F8, F16, F32, F64, F128, F256, F512, F1024, F2048 and F4096, up to F8192 with 8,192 CUs. Price scales linearly with CUs, so an F4 costs twice an F2.

For orientation, the East US pay-as-you-go rate is $0.18 per CU per hour, so an entry-level F2 is $0.36 an hour (about $263 per month running nonstop) and an F64 is $11.52 an hour (about $8,410 per month), per the Azure Retail Prices API on 16 October 2026. Other regions differ. The important behavior is that a capacity has a fixed amount of compute that Fabric lets workloads burst above and then smooths: interactive operations over a minimum of five minutes and up to 64 minutes, background operations over 24 hours. Only when smoothed usage uses up future capacity does throttling start, in stages: overage protection covers the first 10 minutes of future capacity, then new interactive operations are delayed by 20 seconds, then rejected once the next hour is used up, and all new requests are rejected beyond 24 hours. By default that means an undersized capacity shows up as slow reports and rejected jobs, not a bigger invoice. Two opt-in exceptions change that: capacity overage billing stops throttling but costs three times the normal capacity rate, and Autoscale Billing for Spark moves Spark jobs to separate pay-as-you-go billing at the standard CU-hour rate, without smoothing or reservation discounts.

Pay-As-You-Go vs Reserved

Every F-SKU can be bought two ways, and the choice is a real cost lever.

Pay-as-you-go (PAYG) is billed per second with a one-minute minimum and no time commitment, and, crucially, you can pause it. Pausing stops the compute meter, which suits development capacities, dev/test environments, or workloads that only run part of the day. One catch: when you pause, the remaining smoothed usage and overages on the capacity are summed and added to your Azure bill. As an illustration, a capacity that runs 12 hours a day on weekdays only is up for 60 of the week's 168 hours, about 36 percent of the always-on compute cost.

Reserved capacity is a one-year or three-year commitment bought in CU increments. Microsoft's pricing page says a reservation "can help you save ~41% when compared to pay-as-you-go"; in East US a one-year reservation lists at $938 per CU per year, about $5,003 per month for 64 CUs against about $8,410 on PAYG. The trade-off is that the reservation discount is applied hourly and unused reserved hours do not carry over, so pausing a reserved capacity saves nothing on the reservation. The decision is simple in shape: reserve the CUs that run more or less continuously, and keep part-time capacities on PAYG so pausing actually saves money. Reserving CUs you could have paused for most of the week is an expensive mistake.

Per-User Licenses and the F64 Cliff

The capacity is only half the license story. People still need per-user licenses, and the rules create a genuine pricing cliff at F64.

There are three per-user tiers. Free is granted on first sign-in and lets a user create non-Power BI Fabric items (lakehouses, notebooks, pipelines) in a workspace on an F or Trial capacity. Pro ($14 per user per month, paid yearly, on Microsoft's Power BI pricing page as of 16 October 2026) is required to create and share Power BI items in any workspace other than My workspace. Premium Per User (PPU) ($24 per user per month, paid yearly) adds most Premium features on a per-user basis, and Microsoft calls it more cost effective when Premium features are needed for fewer than 250 users, but it does not provision a Fabric capacity.

The cliff is this, in Microsoft's own words: on F-SKUs smaller than F64, "each user viewing Power BI content must have Pro, PPU, or an individual trial." On "F64 or larger, users with only a Free license and a viewer role can view Power BI content" at no per-user cost. For an organization with many viewers, this changes the math completely. Below F64 you pay per head to let people look at a report; at F64 you pay for the capacity once and viewing is free. That is why, for organizations with hundreds of viewers, F64 can be the right answer not because the compute is needed, but because it removes the need for a Pro license per viewer.

OneLake Storage

All Fabric data lands in OneLake, the unified storage layer, which uses a pay-as-you-go model billed separately from compute. Hot OneLake storage lists at $0.026 per GB per month in East US and $0.023 in Central US, West US 2 and North Europe (Azure Retail Prices API, 16 October 2026), or roughly $23 to $27 per terabyte, and Microsoft compares the model to services like Azure Data Lake Storage or Amazon S3. Transactions are not billed separately; reads and writes consume capacity CUs instead. A reservation does not cover storage. Storage is usually a modest line next to capacity, but three details are worth knowing.

First, mirroring includes a free allowance: per Microsoft, "Mirroring offers a free terabyte of mirroring storage for every capacity unit (CU) you purchase. For example, if you purchase an F64 capacity, you get 64 free terabytes." Second, and easy to get caught by, the same documentation adds that "you pay for OneLake storage if you exceed the free mirroring storage limit or when the capacity is paused" (Fabric mirroring docs). Pausing saves compute, but it does not make mirrored storage free. Third, deleted files are not free straight away: OneLake soft delete keeps them for seven days, billed at the same rate as active data, and capacities with business continuity and disaster recovery (BCDR) enabled bill storage on a separate, higher meter ($0.0468 per GB per month for hot BCDR storage in East US on 16 October 2026).

Realistic Cost Scenarios

These scenarios are illustrative, not customer data. They use the East US list prices above to show cost structure. Your actual costs will vary by region, reservation choice, license mix, and workload. Verify against current pricing before budgeting.

Small team: a dev capacity, paused off-hours

A small team runs an F2 on PAYG for development and Power BI, paused overnight and on weekends, with a handful of Pro licenses for creators and viewers. Rough monthly shape: an F2 running roughly a third of the hours (under $100 after pausing) plus a few Pro licenses ($14 each per month) plus minimal storage. Total: roughly $150 to $250 per month, with licenses and compute of similar size; each extra Pro user adds $14.

Mid-size: F64 to unlock free viewers

A department with 15 report creators and 300 viewers moves to an F64 specifically so viewers can use Free licenses. Rough monthly shape: F64 on a one-year reservation (about $5,003 per month) plus 15 Pro licenses for creators ($210) plus storage for two or three terabytes (under $100). Total: roughly $5,300 per month. The comparison that justifies it: on a reserved F32 (about $2,501 per month), all 315 creators and viewers would need Pro, adding $4,410 per month for a total near $6,900.

Enterprise: multiple capacities

An enterprise runs several capacities (for example F128 for production plus F64 for a business unit) on reservations, with hundreds of creators on Pro and thousands of free viewers. Rough monthly shape: capacity reservations of about $15,000 for that pair, creator Pro licenses in the low thousands, and OneLake storage scaling with the data estate. Total: well over $15,000 per month, where the main levers are capacity sizing, reservation coverage, and how tightly workloads are packed onto each capacity.

Cost Optimization Strategies

Ranked by impact.

1. Pause PAYG capacities you do not run continuously. The highest-impact lever for part-time workloads. A development or reporting capacity paused nights and weekends can cut its compute cost by more than half, and PAYG exists precisely so you can.

2. Reserve only the capacities that run around the clock. A reservation saves about 41 percent, but it is applied hour by hour and unused reserved hours are lost. Match reservations to continuous workloads and keep intermittent ones on PAYG. Reserving a capacity you would otherwise pause throws away the pause savings.

3. Size to F64 when you have many viewers. If viewer licenses are your cost driver, the jump to F64 (where Free viewers can view Power BI content) often costs less than the Pro licenses it removes. Do the arithmetic on viewer count, not just compute need.

4. Consolidate workloads onto fewer capacities. Because a capacity is a fixed pool, an underused capacity is wasted budget. Packing more workloads onto one right-sized capacity beats running several half-idle ones, as long as you leave headroom for peaks.

5. Monitor with the Fabric Capacity Metrics app. Throttling and smoothing hide overload as slowness rather than cost, so use the metrics app to see whether a capacity is genuinely saturated (size up) or just spiky (leave it and let smoothing absorb the peaks).

Hidden Costs Most Teams Miss

Viewer licenses below F64. The classic surprise. A team sizes a small capacity for its compute, then discovers every one of its report viewers needs a paid Pro license. For a wide audience, this dwarfs the capacity cost and is the main reason to consider F64.

Reservations that pausing cannot reduce. Teams reserve to get the 41 percent discount, then realize pausing no longer saves them anything, because unused reserved hours do not carry over. For anything that is not near-continuous, PAYG plus pausing can be cheaper than a reservation.

Paused-capacity storage and the pause bill. Pausing stops compute but flips mirroring storage from free to billable, so a capacity you pause to save money still bills for its mirrored data. Pausing also bills the smoothed usage the capacity had not yet paid off.

Opt-in overage and Spark billing. Capacity overage billing ends throttling at three times the normal CU rate, and Autoscale Billing for Spark bills Spark at pay-as-you-go rates outside any reservation. Both are useful, and both put a variable line back on an invoice that was otherwise fixed.

Throttling read as a product problem. An undersized capacity does not overspend; it slows down. Teams sometimes chase performance issues that are really a capacity that needs sizing up, or workloads that need spreading across capacities.

Idle over-provisioning. The opposite failure: a capacity sized for a peak that rarely happens bills at full rate all month. Fabric smooths short bursts, so you can often run a smaller SKU than the peak suggests.

Where Dawiso Fits in Fabric Cost Control

Fabric cost control is partly about capacity settings and partly about knowing what is actually on the platform: which items exist, which ones overlap, and who built them. Dawiso does not monitor capacity usage, CU consumption or cost; that stays with the Fabric Capacity Metrics app and Azure Cost Management. What Dawiso adds is the inventory and the business context around it.

The Microsoft Fabric connector brings item metadata into Dawiso's data catalog: lakehouses, warehouses, SQL databases with their views, procedures and columns, notebooks, pipelines, semantic models, reports, Eventhouses, Eventstreams, KQL databases, Real-Time Dashboards, Activator items and user data functions, most of them with who created and last modified it. That gives teams one place to spot overlapping or stale-looking items and ask the people behind them before anything is retired. Dawiso does not record whether an item is read or by whom, so "unused" is a conclusion to confirm in Fabric, not one the catalog makes. For Power BI content, the Power BI connector records which dataset each report uses and which data sources each dataset reads from, an object-level view of lineage rather than a column-level one.

The business glossary addresses duplicate work: when several teams build the same metric on the same capacity, each copy consumes compute, and one documented definition gives them a reason to converge on a single build. For teams extending Fabric with AI, the Dawiso MCP server lets agents that support the Model Context Protocol search the catalog and read object details, lineage and samples, so an agent can work from documented descriptions and attributes rather than guessing at the meaning of a report.

Conclusion

Microsoft Fabric pricing comes down to three components: a capacity F-SKU priced by Capacity Units, per-user licenses with a hard cliff at F64, and OneLake storage on top. The complexity is in the choices around them, and the biggest savings come from three habits: pause PAYG capacities you do not run continuously, reserve only the ones you do, and size to F64 when viewer licenses would otherwise dominate. For a platform comparison, see Databricks vs Microsoft Fabric, and for Power BI within Fabric, see Power BI and Fabric integration.

Sources

Pricing changes often and varies by region. Always confirm current figures against the primary sources below before budgeting.

• Microsoft Azure - Microsoft Fabric pricing (~41% reservation saving, Autoscale Billing for Spark, capacity overage).
• Microsoft Learn - Azure Retail Prices REST API (East US and other regional list prices for Fabric capacity, reservations and OneLake storage, queried 16 October 2026).
• Microsoft Learn - Understand Microsoft Fabric licenses and capacity (F2 to F8192 SKU table, per-second billing with a one-minute minimum, per-user licenses, the F64 viewer rule).
• Microsoft Learn - Understand capacity throttling and smoothing (bursting, smoothing windows, throttling stages, overage billing at three times the rate).
• Microsoft Learn - Pause and resume your Fabric capacity (pausing stops billing; remaining smoothed usage is billed on pause).
• Microsoft Learn - Save costs with Microsoft Fabric Capacity reservations (one- or three-year terms, hourly application, storage not covered).
• Microsoft Learn - OneLake capacity consumption example (storage billed separately, soft delete billed at the same rate).
• Microsoft Learn - Mirroring (1 TB of free mirroring storage per CU, billable when exceeded or when the capacity is paused).
• Microsoft Learn - Microsoft Fabric Capacity Metrics app.
• Microsoft - Power BI pricing (Pro $14 and PPU $24 per user per month, paid yearly).
• Dawiso Help - Microsoft Fabric connector
• Dawiso Help - Power BI connector