How to build a cost model for a Fabric platform
From workloads to capacity units to a monthly figure: a method you can use before you build and test against reality afterwards.
- 01
Map the workloads, not the features
Start with a list of what will actually run: how many sources get loaded, how often, how many semantic models refresh, how many report users there are at peak, and which notebooks or Spark jobs run daily. A list of Fabric items does not help, because a Lakehouse costs nothing until something happens in it.
Note three things per workload: volume, frequency and time of day. That last one matters more than it looks, because capacity is a shared pool: ten heavy refreshes at four in the morning need less capacity than three at once at nine.
- 02
Translate to capacity units
Fabric bills in capacity units. An F64 delivers 64 CU of concurrent processing; anything above that gets throttled or delayed through smoothing and bursting.
The honest answer is that you cannot make that translation exactly up front. What does work:
- Take an existing, comparable workload and measure it with the Capacity Metrics app.
- Scale linearly on volume, not on user count. A report viewed by fifty people does not consume fifty times what one person does.
- Model two scenarios: expected volume and twice expected volume. The second is your conversation about growth.
- 03
Model storage and compute separately
OneLake storage bills per terabyte per month and is usually a small part of the total. Compute is the bulk. Still keep them apart in your model, because they behave differently: storage grows steadily with history, compute jumps with every change in frequency.
Do not forget mirroring and the copies you make yourself. A medallion architecture with bronze, silver and gold holds the same facts three times, and that is a deliberate choice with a price tag.
- 04
Add the licences
Fabric capacity covers processing, not consumption. Below F64 anyone viewing a report needs a Power BI Pro licence; from F64 upward that requirement drops for viewing content in workspaces on that capacity. That is exactly where the sum flips: a larger capacity can work out cheaper than a smaller one plus hundreds of licences.
Model both variants and put them side by side in the same table. This is the most common blind spot in a Fabric cost model.
- 05
Choose pausing or reserving
A capacity that is only needed during office hours can be paused, and while paused you pay no compute. That is attractive for development and test capacity but unusable for production with overnight loads.
A reservation gives a discount for a fixed term. The rule: reserve the part that is needed twenty-four hours a day and keep the variable part pay-as-you-go. Do not do this in month one, but as soon as you have two months of real measurement.
- 06
Test the model afterwards
A cost model is a prediction, so you should measure whether it held. After go-live, set up a recurring comparison between predicted and actual distribution per workload. Wherever the model was off by more than a quarter there is almost always an assumption you need to make explicit: a refresh running more often than assumed, a report doing live query instead of import, or a pipeline doing full loads where incremental was intended.
What this gives you
A cost model that goes through these six steps gives you three things: a figure you can defend, a list of assumptions you can test, and a conversation with the business about volume instead of technology. That last one is the real return.
The process at a glance
Click a step for its key decision
Map the workloads, not the features
This step has no explicit decision, but builds on the previous one.
Read next
Related patterns
Related use cases
Related best practices