Microsoft has finally introduced a capacity tier that many of us have been looking forward to, including me. It’s the new F0 capacity SKU.
One big step towards a truly serverless Fabric experience, where you no longer need to provision a minimum compute capacity. Instead, you pay for what you actually consume. Sounds great, right? Well, yes. But those of us who've been around cloud technologies for a while know that serverless doesn't necessarily mean cheaper.
Because pay-as-you-go doesn't mean every workload costs the same.
The key point to pay attention to is that on-demand compute has different pricing multipliers depending on the Fabric workload. Some are charged at 1x the standard pay-as-you-go CU rate, while others can reach 3x!
(As of writing, Microsoft has not yet published a detailed list of F0 workloads and their pricing rates, so keep an eye out for updates.)
The question isn't whether F0 is cheaper than a fixed cost capacity. It's whether it's cheaper for your specific workload.
The most obvious use case for F0 is testing and experimentation. If you're exploring Fabric or trying out a new workload, you might not need a continuously provisioned capacity. Instead, F0 allows you to pay based on consumption, making it an interesting option for workloads that don't need to run all the time.
However, where things get really interesting is when we look at how OneLake compute consumption is charged.
As a general rule, the serving capacity pays for OneLake data-access operations. But there is one important exception to this rule: internal OneLake shortcuts between Fabric capacities! In this case, the read operations are charged to the consuming capacity instead Understanding this distinction creates opportunities for some interesting architectural patterns.
Let's look at the shortcut scenario. Imagine that you have a Dataverse environment that is running in a different Azure region than your main Fabric capacity. Connecting Dataverse directly to Fabric across regions is possible, but depending on your setup, you might end up paying additional data transfer costs. What if you instead created a separate Fabric capacity in the same region as Dataverse, and used Fabric Link to bring that data into OneLake? Your main Fabric capacity could then access the data through an internal OneLake shortcut.
Why would you go through that extra hoop, because when you read data through an internal shortcut, it's the consuming capacity that pays for the OneLake read operations, rather than the capacity where the data is stored. And because of that, you could actually pause the capacity hosting your Dataverse data and still access it from your main Fabric capacity.
In other words, you wouldn't necessarily need to keep a second capacity running just to make the data available. It could act as a landing point, while your main capacity takes care of the consumption. Because data can be read through a shortcut even if the capacity is paused. Depending on the setup, that could also mean lower costs.
So, should you replace your F2 with F0?
Not necessarily. And here's where I'd throw in a good old "it depends." Do you know which workloads consume your Fabric capacity, how frequently they run, and what they actually cost? Because if you don't know what your workloads cost today, predicting what they'll cost on F0 won't be easy.
My takeaway: I really like the direction Microsoft is taking with F0. It lowers the entry barrier and creates new opportunities for serverless and multi-platform architectures. But flexibility comes with a responsibility to understand consumption. For the right use case, F0 could be significantly cheaper than F2. For another, quite the opposite. Serverless gives us flexibility. But making the most of it still comes down to understanding our workloads.
Note: As far as I’m aware, F0 capacity is not yet available in any European Azure regions. Microsoft has announced that it will be released in Public Preview, but no official release date for Europe has been communicated at the time of writing.
If you're interested in exploring how an F0 capacity could fit into your Fabric architecture, feel free to reach out. We'd be happy to guide you through your capacity planning process and help you find the right fit for your organization's needs, requirements, and budget. info@masterminds.io
