Fabric capacity sizing for Dynamics 365 analytics: what actually drives CU consumption

Microsoft does not publish a table that maps company size to a Fabric SKU. The capacity a Dynamics 365 analytics stack needs depends on how many people open reports at once, how big the fact tables are, how often models refresh, and what runs in the background between refreshes. Report queries, refreshes, and transformations each consume capacity units (CUs), and Fabric smooths interactive and background work over different windows, so the reliable way to size a capacity is Microsoft’s: measure the real workload and scale until it fits. For the license side of the move from Power BI Premium, see the Power BI Premium retirement guide.

The short answer: size by measuring, in five steps

1. Pick the peak to size for. For finance, that is month-end and quarter-end close, when many users open the same reports at once.
2. Run the workload on a Fabric trial or a pay-as-you-go F SKU, with real D365 data volumes and a pilot group of users.
3. Read the Capacity Metrics app: utilization, the throttling tab, and the timepoints at the peak.
4. Scale the capacity until the peak fits without throttling, and check the two limits that can decide the SKU regardless of utilization: memory and Direct Lake guardrails, and the F64 line for free viewers.
5. Reserve the size your normal weeks need, plan a scale-up for close, and keep measuring after go-live.

What a capacity unit buys

Fabric measures consumption in CU-seconds, evaluated every 30 seconds. A SKU’s allowance per 30-second timepoint is its CU count multiplied by 30, so an F64 has 1,920 CU-seconds per timepoint and 1,536 CU-hours a day. Each engine converts its own unit to CUs: Microsoft lists eight CUs per Power BI v-core, two Spark VCores per CU, and 0.538 CUs per Fabric Data Warehouse core, and says these rates can change. The table also lists each SKU’s Direct Lake row limit, model memory, and free-viewer rule.

F SKU	CUs	CU-seconds per 30-second timepoint	CU-hours a day	Direct Lake rows per table	Max memory per semantic model	Free viewers
F2	2	60	48	300 million	3 GB	No
F4	4	120	96	300 million	3 GB	No
F8	8	240	192	300 million	3 GB	No
F16	16	480	384	300 million	5 GB	No
F32	32	960	768	300 million	10 GB	No
F64	64	1,920	1,536	1,500 million	25 GB	Yes
F128	128	3,840	3,072	3,000 million	50 GB	Yes
F256	256	7,680	6,144	6,000 million	100 GB	Yes

Microsoft maps F64 to P1, a Premium SKU being retired, and to A4 for comparing compute, and says the mapping is not a statement of functional or licensing equivalence.

How Fabric charges a spike: smoothing, carryforward, and throttling

Fabric does not stop a job that needs more than the SKU provides in one timepoint. It lets the job run (bursting) and spreads the accounting across future timepoints (smoothing). Interactive operations are smoothed over a minimum of five minutes and up to 64 minutes, depending on how many CUs they use. Background operations are smoothed over 24 hours. Microsoft’s example: a background job that used 1 CU-hour on an F2, which has 48 CU-hours a day, adds about 2.1% to each timepoint, so the capacity is not throttled even though the job used more CUs than an F2 provides in ten minutes (3,600 CU-seconds against 1,200).

When smoothed usage in a timepoint exceeds the SKU, the excess becomes carryforward, which later timepoints pay off with their unused CUs. Throttling depends on how much future capacity is already spoken for:

Future capacity already used	What happens to new requests
Up to 10 minutes	Nothing: overage protection
10 to 60 minutes	New interactive requests, such as report queries, are delayed 20 seconds
60 minutes to 24 hours	New interactive requests are rejected; background jobs can still start
More than 24 hours	All new requests are rejected until the carryforward is paid off

Operations already running are not throttled, and throttling applies per capacity, so one overloaded capacity does not slow another. Rejected users see messages such as “Cannot load model due to reaching capacity limits”. For a finance team, the risk is the third row on close day: new report queries are rejected while background jobs, such as refreshes, can still start. When capacity overage is on, which is the default for new capacities, Fabric bills the excess instead of throttling until the overage threshold is reached.

What consumes CUs in a D365 F&O analytics stack

Operation	Interactive or background	What drives it
Opening reports and using visuals, including loading model data into memory	Interactive	Concurrent users, visuals per page, DAX complexity, and row-level security filters
Import semantic model refresh	Background	Data volume and how often you refresh
Direct Lake reframing	Not listed by Microsoft as its own operation	A low-cost step that reads Delta table metadata, usually in a few seconds; changed columns are reloaded into memory on the next report query, which is interactive
Queries on a lakehouse’s SQL analytics endpoint	Background	Query volume and complexity
Notebooks, Spark jobs, and materialized lake views	Background	The transformations you run on the linked F&O tables
Pipelines	Background	1.5 CU-hours per throughput unit for copy activities; 0.0056 CU-hours per other activity run
Dataflow Gen2	Background	12 CUs per second of query time for the first 10 minutes, then 1.5 CUs per second (CI/CD dataflows); 16 CUs per second for other dataflows
OneLake reads and writes	Background	104 CU-seconds per 10,000 reads, counted in 4 MB blocks, and 1,626 CU-seconds per 10,000 writes; storage itself is billed per GB, not in CUs

Microsoft said that from October 15, 2026, Fabric would start counting some OneLake operations from Spark workloads that it did not fully report before. Rates are unchanged, but Microsoft warns that Spark-heavy workloads may see higher CU consumption, so a transformation layer measured before that date may read higher now.

For D365 F&O, five factors multiply these operations:

• Close-day concurrency. Interactive smoothing lasts minutes, not hours, so many controllers opening the same finance reports at once is the likeliest trigger for the 20-second delay. Fresher Link to Fabric data moves more report checking into the close day itself; see what fresher F&O data changes for month-end close.
• Fact-table size. GeneralJournalAccountEntry and InventTrans are usually among the largest F&O tables. Their size drives refresh cost in Import and memory in Direct Lake.
• Refresh cadence. In Import, each refresh is a background operation smoothed over 24 hours, so a refresh every 15 minutes is 96 refreshes a day on the same allowance. In Direct Lake, the reframe itself is cheap; the cost moves to the transformations that write new data each cycle and to reloading changed columns on the next report query.
• Number of models and reports. Each semantic model is refreshed and held in memory separately, and duplicated models multiply both.
• Model design. Microsoft lists the usual causes of high interactive CU: models without a star schema, complex row-level security filters, inefficient DAX measures, report pages with too many visuals, and high-cardinality visuals.

What Link to Fabric consumes, and on whose bill

Link to Fabric keeps a Delta copy of the selected F&O tables in Dataverse storage, and that copy counts toward your organization’s Dataverse database capacity, shown under database usage in the Power Platform admin center. Only selected tables consume storage, so the table selection is a cost lever. Microsoft does not document Fabric CUs for the sync itself. What shows up in the Metrics app is the work done on the linked tables: transformations, SQL analytics endpoint queries, semantic model refreshes, and report queries. For shortcuts within OneLake, Microsoft bills reads to the capacity of the workspace that holds the shortcut; it does not say how reads through the Dataverse-managed shortcuts are counted, so check the OneLake rows in the Metrics app during a pilot. For what the link gives you and what you still build on it, see Link to Fabric for D365 F&O.

Since October 23, 2026, Microsoft Learn says the Fabric capacity and workspace no longer have to be in the same Azure geography or region as the Dataverse environment. A Direct Lake model still has to be in the same region as its source lakehouse workspace.

Business Central is a different case: Link to Fabric does not carry its ledger data. The routes that do are compared in Business Central to Microsoft Fabric: what changes for BC reporting.

Two limits that can pick the SKU before CUs do

Memory and Direct Lake guardrails. Each SKU caps the rows, Parquet files, and row groups per Direct Lake table and, on F2 to F32, the model size on OneLake (10 to 40 GB). Import models are capped by max memory, which for Direct Lake is a paging ceiling, not a guardrail. On Direct Lake on OneLake, a table over a guardrail makes the refresh fail, and the model cannot be queried until the tables are optimized or the capacity is scaled up; on Direct Lake on SQL endpoints, the model falls back to slower DirectQuery if fallback is enabled. An Import refresh can more than double a model’s memory, because the old copy keeps serving queries until the refresh commits. Capacity overage adds CUs, not memory, and the Metrics app does not show Power BI memory metrics, so check the largest F&O fact tables against these limits early. The full guardrail table is in Direct Lake vs import for D365 F&O.

Viewer licensing. On F64 and larger, users with a free license and the workspace Viewer role can view Power BI content. Below F64, every viewer needs Power BI Pro, listed at $14.00 per user per month, or Premium Per User at $24.00. A large, read-only finance audience can make F64 the cheaper option even when an F32 has the CUs; the break-even is worked out in the Premium retirement guide.

Measure before go-live

• Trial or pay-as-you-go. The Fabric trial is free for 60 days and is set up as either an F4 or an F64 capacity, so check which one you have before you read anything into it; eligible tenants can raise 4 CUs to 64. Microsoft says the trial is for evaluation, not production, and that Dataflow Gen2 pricing does not apply to trial capacities, so confirm dataflow costs on a paid capacity. A pay-as-you-go F SKU gives billable numbers and can be scaled during the test.
• The SKU Estimator, as a starting point only. Microsoft’s Fabric SKU Estimator is still in preview and warns that its estimates may not be accurate. It asks for compressed data size, daily batch cycles, number of tables, daily report viewers and creators, an optional model size, and Dataflow Gen2 hours. It does not ask for semantic model refresh cadence, storage mode, report count, or concurrency at close.
• Replay a close. Microsoft’s Premium migration guidance says to validate the baseline across a full business cycle, including month-end and quarterly close. Microsoft’s Fabric capacity planning guide suggests piloting with about 10 to 15 percent of the eventual users while watching the Metrics app, and developing on a separate non-production capacity.
• Check quota first. Creating an F SKU needs enough Fabric CU quota in the Azure subscription and region: an F64 needs 64 available CUs. Quotas are free and can be raised through Azure Quotas.

Measure after go-live: reading the Capacity Metrics app

• Compute page. The utilization chart shows background percentage in blue and interactive percentage in red against the CU limit line, over the last 14 days. Select a day to see 30-second detail. Utilization above 100% does not by itself mean throttling.
• Throttling tab. Three lines matter: 10-minute interactive percentage against the delay threshold, 60-minute interactive percentage against rejection, and 24-hour background percentage against background rejection. A value above 100% means that stage is active, unless capacity overage is on: the chart then shows No interactive delay (capacity overage billed), and the excess is billed at three times the pay-as-you-go rate instead of throttled.
• Overages tab and system events. The carryforward view shows how much was borrowed and how fast it burns down. The system events table records when the capacity changed state and why, such as interactive delay or interactive rejection.
• Timepoint drill-through. Open the peak timepoint on close day. The interactive table shows which reports and users drove it; the background table lists every background operation that completed in the previous 24 hours, with its share of that timepoint. Failed operations still count.
• Keep history. Usage appears 10 to 15 minutes after the activity, the app keeps 14 days, and it has no alerts. Microsoft’s migration FAQ suggests reviewing 30 to 45 days, so stream capacity operation events from Real-Time hub into an Eventhouse to keep a longer record, and set Activator alerts on capacity overview events; the eventstream and Eventhouse consume CUs themselves.

Controls when the capacity runs hot

• Capacity overage. Generally available for F SKUs and on by default for new capacities, with a default threshold of 25% over a rolling 24 hours. It bills the excess at three times the pay-as-you-go rate and is checked every five minutes, so it is not a hard spending cap. Turning it on during heavy throttling bills the whole carryforward at that moment, and Microsoft warns to take care when scaling down with it on.
• Surge protection. At capacity level, it rejects new background jobs when 24-hour background usage reaches the threshold you set, which keeps refreshes and transformations from using up the capacity report users need, though Microsoft says it does not guarantee that interactive requests are never delayed. Workspace-level limits are in preview. Microsoft’s advice for critical reporting is to isolate it on its own capacity.
• Scale up. CUs above any reservation bill at the pay-as-you-go rate. Moving from below F64 to F64 or larger is almost immediate, but license updates usually take up to a day and can take longer, and free users may be asked for Pro until they finish, so scale up before close, not during it. Crossing the boundary between F256 and F512 can briefly interrupt the capacity and cancel running jobs.
• Scale out. Move workspaces to a second capacity, for example a dedicated capacity for finance reporting, so transformations and report queries do not share one allowance.
• Pause. Only pay-as-you-go F SKUs benefit. On pause, the smoothed usage still owed is billed at once and content becomes unavailable; OneLake storage is still billed.
• On-demand billing for Spark. An opt-in setting runs Spark jobs on serverless compute billed separately, outside the capacity’s CUs. Microsoft’s September 2026 feature summary lists broader on-demand billing and a zero-provisioned F0 capacity as coming soon.

Pay-as-you-go first, then reserve

Microsoft suggests starting small. In the Azure price list on November 2, 2026, pay-as-you-go in Central US and East US is $0.18 per CU-hour, so an F64 costs $8,409.60 a month at 730 hours. A one-year reservation is $938 per CU, about $5,002.67 a month for an F64, which Microsoft describes as about 41% less. West Europe is $0.22 per CU-hour. A reservation applies hour by hour and unused CUs do not carry over: a 64-CU reservation on an F32 loses 32 CUs every hour, and an F128 bills the extra 64 CUs at pay-as-you-go. That makes a common pattern cheaper than reserving for the peak: reserve the size your normal weeks need, and scale up for close, paying pay-as-you-go only for the extra CUs. Reserve the close-day size only if the peak lasts most of the month, or if free viewers need F64 all the time.

Where Metrixs fits

Metrixs runs in your own Microsoft Fabric environment, and the capacity size depends on company size, data volume, the number of reports, and users. On the Standard plan, reports use Direct Lake and refresh every 15 to 30 minutes, depending on data volume, the number of reports, and Fabric capacity. Metrixs adds 150+ pre-built Power BI reports with 1,200+ metrics for D365 F&O. See Microsoft Fabric for D365 F&O, or request a demo and see if you qualify for a free 6-month trial.

FAQs

1. What F SKU do I need for Power BI on Dynamics 365 F&O?

Microsoft does not publish a table that maps company size to an F SKU. Its method is to run the real workload on a trial or pay-as-you-go capacity, read the Capacity Metrics app, and scale until the capacity covers it. For D365 F&O, run that test through a month-end close, and check two limits that can decide the size before capacity units do: the F64 line for free report viewers, and Direct Lake’s rows-per-table guardrail (300 million rows on F2 to F32, 1,500 million on F64).

2. Do Dynamics 365 users need a Power BI Pro license if we buy an F32?

Yes, for Power BI content hosted on the F32. On F SKUs smaller than F64, every user who views that content needs a Pro, Premium Per User, or individual trial license. On F64 and larger, users with a free license and the workspace Viewer role can view content. Report authors need Pro or Premium Per User on any SKU.

3. Does Link to Fabric use our Fabric capacity units or our Dataverse storage?

The copy that Link to Fabric keeps counts toward your Dataverse database capacity, and only the tables you select consume it. Microsoft does not document Fabric capacity units for the sync itself. The capacity units you see in the Metrics app come from what you build on the linked tables: transformations, SQL queries, semantic model refreshes, and report queries.

4. What happens to our reports if the Fabric capacity is throttled during month-end close?

It depends on capacity overage and on how far ahead the capacity has borrowed. When overage is on, which is the default for new F SKU capacities, Fabric bills the excess at three times the pay-as-you-go rate instead of throttling until the overage threshold is reached. Otherwise, up to 10 minutes of future capacity, nothing happens. From 10 to 60 minutes, new report queries wait 20 seconds. From 60 minutes to 24 hours, new report queries are rejected while background jobs such as refreshes still start. Beyond 24 hours, every new request is rejected until the borrowed capacity is paid back. Operations already running are not stopped.

5. Can we pause the Fabric capacity at night to save money?

Only pay-as-you-go F SKUs benefit. When you pause, the smoothed usage still owed is added to your Azure bill at once, and reports and queries on that capacity are unavailable until you resume. A reservation applies hour by hour and does not carry over, so pausing a reserved capacity saves nothing unless another capacity in the reservation’s scope can use those CUs that hour.

Sources

All pages below were checked on November 2, 2026.

• Microsoft Fabric concepts and licenses
• Plan your capacity size
• Fabric operations
• The Fabric throttling policy
• Capacity overage overview
• Surge protection
• What is the Microsoft Fabric Capacity Metrics app?
• Capacity Metrics app: Compute page
• Capacity Metrics app: Timepoint page
• Fabric capacity operation events in Real-Time hub
• Microsoft Fabric SKU Estimator (preview)
• Fabric trial capacity
• Power BI Premium to Fabric migration FAQ
• Pause and resume your capacity
• Scale your Fabric capacity
• Evaluate and optimize your Fabric capacity
• OneLake compute and storage consumption
• Direct Lake overview
• How Direct Lake works
• Semantic model limits by SKU
• Pricing for pipelines
• Pricing for Dataflow Gen2
• On-demand billing for Spark
• Save costs with Microsoft Fabric capacity reservations
• Buy a Microsoft Fabric subscription
• Microsoft Fabric link FAQ
• Link your Dataverse environment to Microsoft Fabric
• Microsoft Fabric pricing
• Microsoft Fabric SKU Estimator tool
• Plan your first Fabric deployment
• Power BI Premium to Fabric migration overview
• Power BI pricing