Microsoft Fabric Pricing in Euros: What You Actually Pay Each Month

Scenario: The BI Team That Accidentally Bought a Truck

Picture a BI team in a mid-sized organisation:

• 25 analysts with Power BI Pro
• 3 Fabric enthusiasts who turned on the Fabric trial and then moved to paid
• 1 production workspace hosting:
  • A lakehouse with ~2 TB of parquet data
  • 5 Power BI semantic models (mixed Import / Direct Lake)
  • A couple of Data Factory pipelines and one Data Warehouse

Finance sees the first full month of Fabric and asks a simple question:

“What are we actually paying for in euros, and what can we control?”

We’ll use this scenario as a thread:

• Which Fabric SKUs matter
• How they convert into monthly euro costs
• How storage, compute and user licences interact
• Concrete changes that reduce the bill without killing throughput

Everything here is aligned with Microsoft’s current public documentation as of late 2026. Details can change, so always cross-check the exact SKUs and prices in your tenant.

The Three Big Buckets of Fabric Cost

For a typical production Fabric setup, your recurring monthly spend comes from three main areas:

1. Capacity (F SKUs) – shared compute for Fabric items and Power BI
2. User licences (Power BI Pro / Premium per user) – who can publish and consume
3. Storage (OneLake) – how much data you keep, and where

Let’s unpack each, then map them to our scenario.

1. Capacity: F SKUs and How They Meter Usage

Fabric uses capacity SKUs (F-series) that are billed per hour. The key points:

• You buy an F capacity (e.g. F2, F4, F8…) at a fixed hourly rate.
• That capacity is assigned to one or more workspaces.
• All Fabric items in those workspaces (lakehouses, warehouses, pipelines, notebooks, semantic models, reports) run on that capacity.

Core behaviours that matter for cost:

• Billing unit: capacity is billed per hour, with usage metered at the SKU’s hourly rate; Azure billing shows the actual metered hours rather than simply rounding every partial hour up to a full hour.
• Scaling: you can scale up/down between F SKUs; the price per hour changes accordingly.
• Pausing: Fabric capacities can be paused; during paused periods, compute charges stop but items hosted there are not available.
• Workload sharing: multiple workloads share the same capacity. Heavy Data Engineering jobs can slow down BI refreshes if you don’t manage concurrency.

From a euro perspective:

• Microsoft publishes regional prices per F SKU, usually in the local currency (for EU tenants, often euros). The actual euro rate depends on:
  • Your tenant’s billing region
  • Any enterprise agreement discounts
• The monthly cost is roughly:

Monthly € ≈ Hourly € rate × metered hours active in month

For our scenario, suppose they run a single F4 capacity 24×7 for production. Their monthly compute cost is simply:

• 24 hours × number of days in month × F4 hourly rate in euros

The team can’t control the hourly price itself, but they can control:

• Which SKU they use (F2 vs F4 vs F8)
• How many hours it runs (schedule vs always-on)

2. User Licences: Pro vs Premium Per User in a Fabric World

Fabric capacity does not remove the need for user licences.

Key licence types relevant here:

• Power BI Pro
  • Required for most authors to publish reports to workspaces.
  • Required for sharing content from non-Premium workspaces.
• Power BI Premium per user (PPU)
  • Gives a single user most Premium features (larger dataset sizes, some advanced features).
  • Works without a dedicated capacity; it’s a user-based entitlement.
• Fabric capacity (F SKUs)
  • When a workspace is on an F capacity, viewers of content in that workspace generally do not need Pro, as long as they access via the supported methods for Premium/Fabric (for example, using the Power BI service with free licences against a workspace backed by Fabric capacity).
  • Authors still typically need Pro to publish content, unless your organisation uses other licence combinations.

In euros:

• Pro and PPU licences are billed per user per month.
• The euro price is fixed per licence type in your region, not metered by usage.

In our scenario:

• 25 analysts on Power BI Pro – fixed monthly euro cost
• 3 Fabric champions could be:
  • Pro only (using the shared F capacity), or
  • PPU if they need Premium features in non-Fabric workspaces

You can lower licence cost by:

• Reducing the number of Pro users who actively publish
• Moving more consumers to “view-only via Fabric capacity” where appropriate

3. Storage: OneLake and Related Data Stores

Fabric uses OneLake as the unified storage layer. Under the hood, this is metered as storage in your tenant’s region.

Key behaviours:

• Lakehouse / Warehouse data is stored in OneLake.
• Power BI semantic models in Import mode effectively store compressed data; this contributes to storage usage.
• Direct Lake semantic models read directly from OneLake files; they don’t duplicate the data, but metadata and cache still exist.

Storage billing characteristics:

• Charged per GB per month, typically measured as average or peak usage, based on the storage meters exposed for Fabric/OneLake in your billing account.
• Separate rates for:
  • Hot storage (primary OneLake data)
  • Any backup or geo-redundant options, depending on your configuration

In our scenario:

• ~2 TB of parquet in the lakehouse
• Additional storage for:
  • Staging tables in the Data Warehouse
  • Historical snapshots in pipelines
  • Semantic model storage for Import datasets

Storage euro cost is:

Monthly € ≈ (Total TB stored) × (€/TB/month rate in your region)

You control cost by:

• Reducing retained volume (archiving outside Fabric, pruning history)
• Avoiding duplicate storage (Import + Direct Lake of the same data when not needed)

How the Bill Actually Shows Up in Euros

For most organisations, Fabric-related charges appear in one of two places:

• Microsoft 365 / Power BI billing (user licences)
• Azure billing / Cost Management (Fabric capacities and storage)

The important practical points:

• If your billing currency is euros, the portal shows € amounts per resource.
• Fabric capacities appear as Azure resources (e.g. a capacity resource with an F SKU).
• OneLake storage usage is reflected in your Fabric-related resource meters in Azure Cost Management (rather than as a traditional standalone storage account).

To answer finance’s question, you need to map:

1. Euro cost per F capacity per month
2. Euro cost per licence type per month
3. Euro cost per TB of storage per month

Then connect them to:

• Workspaces (which are on which capacity)
• Data volume per solution (which lakehouses/warehouses hold what)
• User groups (which teams actually need Pro/PPU)

Walking the Scenario: What This Team Actually Pays

Let’s walk through our BI team’s month.

Capacity Cost: One F4 Running 24×7

Assume:

• 1 production capacity: F4
• Always on, all month

The monthly compute cost is:

• F4 hourly rate in euros × total hours in the month

They could reduce this by:

• Scaling down to F2 outside business hours if workloads allow
• Pausing capacity in non-production tenants overnight

But for a production workspace with refreshes and near-real-time pipelines, fully pausing is often not acceptable.

Licence Cost: 25 Pro Users, Optional PPU

The team’s licence bill:

• 25 × Pro monthly euro price
• Optional: additional PPU licences for power users in non-Fabric workspaces

If most consumption is via the Fabric-backed production workspace, they might:

• Keep Pro for authors and admins
• Consider whether some report consumers can use free accounts viewing content hosted on Fabric capacity (subject to your organisation’s licensing setup and governance)

Storage Cost: 2 TB and Growing

The lakehouse holds ~2 TB of parquet. Over time, this grows as:

• Pipelines add new partitions
• Snapshots accumulate

Fabric doesn’t charge per file; it charges per stored volume.

The team can:

• Implement retention policies (e.g. keep 18 months of detailed data, aggregate older periods)
• Move very cold history to cheaper storage outside Fabric if they don’t need it in OneLake

Practical Cost Controls That Don’t Break Production

Here are cost levers that actually work in a Fabric environment, mapped to the scenario.

1. Right-Size Capacity to Workload Patterns

Instead of running a single F4 24×7, the team can:

• Monitor CPU and memory utilisation for the capacity in the admin portal.
• Identify peak windows (e.g. 06:00–09:00 refresh, 09:00–17:00 interactive reporting, 17:00–02:00 heavy batch loads).

Then:

• Use a higher SKU during heavy windows if needed, and
• Scale down during quiet windows.

Effect on euros:

• Hours at higher SKUs cost more; hours at lower SKUs cost less.
• The net monthly cost can drop if the capacity spends many hours at a lower tier without impacting SLAs.

2. Move Consumers Off Pro Where Fabric Capacity Covers Them

If your organisation uses Fabric capacities for production workspaces:

• Consumers who only view content in those workspaces can often use free accounts.
• Authors and dataset owners still need Pro.

For the scenario team:

• Identify users who never publish, only view.
• Move them from Pro to free where licensing rules allow.

Effect on euros:

• Direct reduction in per-user licence cost

3. Cut Duplicate and “Zombie” Storage in OneLake

Run a simple storage hygiene pass:

• List lakehouses and warehouses with large volumes.
• Check for:
  • Duplicate copies of the same source data
  • Pipeline staging areas that are never cleaned
  • Semantic models that duplicate large fact tables in Import mode while a Direct Lake option exists

Actions:

• Consolidate lakehouses where appropriate.
• Add cleanup steps to pipelines to drop temporary tables.
• Switch semantic models to Direct Lake when:
  • Query patterns allow it
  • Latency and feature constraints are acceptable

Effect on euros:

• Lower total TB stored → lower monthly storage cost.

4. Use Separate Capacities for Dev/Test vs Production

Mixing dev/test with production on the same capacity can:

• Force you into a higher SKU than production alone needs.
• Cause unpredictable spikes from experiments.

Practical pattern:

• Small F SKU for dev/test, scheduled or even paused when not used.
• Right-sized F SKU for production only.

Effect on euros:

• Dev/test capacity can run fewer hours or at a smaller SKU.
• Production capacity is sized for predictable workloads, not experiments.

Quick Sanity Check: Are You Overpaying?

For your own tenant, answer these questions:

1. Capacity

   • Do you have any F capacities running 24×7 that could safely be paused or scaled down for part of the day?
   • Are dev/test and production separated?

2. Licences

   • How many users truly need Pro to publish vs only view content on Fabric-backed workspaces?
   • Are you paying for PPU where an F capacity would cover the same features for that user’s workspaces?

3. Storage

   • Which lakehouses/warehouses hold the bulk of your TBs?
   • Can you archive older data outside Fabric or aggregate it to reduce detail volume?

If you can clearly answer these in terms of euros per month, you’re in a much better place when finance asks for justification or cuts.

One Concrete Takeaway

Before you touch any workloads, open your billing portal and tag each Fabric-related resource (F capacities, storage, licences) back to a specific workspace and team. Once finance sees a clean mapping from euros to actual solutions, you can negotiate realistic optimisations instead of blanket cuts that break production.