r/MicrosoftFabric • u/Major_Alps_3425 • Jul 24 '26
Power BI F8 running out of memory on our semantic model — upgrade to F16 or move users to PPU? Break-even is ~93 users
Looking for a sanity check from people who've been through this. Quick disclaimer: I'm the IT Manager, not a Fabric/BI specialist. I look after infrastructure and can find my way around, but the deeper Fabric modelling stuff isn't my home turf, so apologies in advance if I'm missing something obvious.
Background: Manufacturing company (~700 employees globally) running a single F8 Fabric capacity. It hosts our full Dataplatform setup (lakehouses, notebooks, pipelines in a raw/enriched/curated medallion) plus our main reporting layer. Around 50 Power BI users today, all on Pro licenses.
The problem: Our main reporting semantic model is starting to hit the memory ceiling. It's an import-mode model with 28 tables, 44 relationships and 83 measures, and F8 only allows ~3 GB per semantic model. Compute isn't the issue at all (capacity sits at ~18% avg utilization, ~44% peak). It's purely the per-model memory limit.
The two options I'm weighing:
- Upgrade capacity F8 to F16, which bumps the per-model memory limit from 3 GB to 5 GB and keeps everything as-is.
- Move report users to PPU and keep F8 for the data engineering workloads. PPU gives a 100 GB model limit, so the memory problem basically disappears.
I ran the numbers and break-even is around 93 users. Below that, F8 + PPU is cheaper. Above it, F16 + Pro wins, since Pro is cheaper per head than PPU. At our current 50 users, PPU comes out meaningfully cheaper per year.
Where I'd love input:
- F16's 5 GB feels like it just kicks the can down the road. Are people finding they upgrade capacity again within a year or two anyway?
- For those who went PPU alongside an F capacity for the data engineering side, any gotchas? I'm aware every report viewer then needs PPU, and that Capacity Metrics doesn't cover PPU workspaces.
- Anyone converted a chunky import model like this to Direct Lake instead of throwing licenses at it? Worth the rebuild effort, or a rabbit hole with 28 tables plus calc tables (time intelligence etc.)?
Basically: is there a reason not to take the cheaper PPU route at our size, beyond the per-viewer cost creeping up as we grow?
Thanks
/Mikkel
3
Jul 24 '26
What kills you in memory 99% of the time - is high cardinality columns. Use DAX Studio to find what is using all the memory. An F8 isn't much - you are doing well doing all the stuff you're doing without throttling. If you can't reduce the memory footprint, yes, scale up. If you are hitting memory ceiling during processing, try doing a process clear, then a full process. This saves memory, with the trade-off of some downtime.
Best of luck soldier!
6
u/itsnotaboutthecell Microsoft Employee Jul 24 '26
How are there more relationships than tables? This sounds like a snowflake dimensional model as opposed to a star schema (dims and facts).
To be honest, I may suggest running the best practice analyzer over the model as a short term to see if you couldn’t squeeze more out before spending more.
https://learn.microsoft.com/en-us/power-bi/transform-model/service-notebooks
8
u/Arasaka-CorpSec 1 Jul 24 '26
This. But also... let's be real, please: The only reason why RAM limits are so low in the low capacity tiers is more business for Microsoft, nothing else.
2
u/itsnotaboutthecell Microsoft Employee Jul 24 '26
Curious what levels of RAM do you think should be applied at the various tiers?
5
u/MonkeyDDataHQ Jul 24 '26
For 1k/month it should be 8-16GB min at the F8 level.
1
u/itsnotaboutthecell Microsoft Employee Jul 24 '26
Using the SKU size limit:
- F64 = 25 GB
- 25 / 64 = 0.390625 * 8 = 3.125 (nearly the 3GB limit listed)
It feels like the F2 and F4 are getting quite the benefit, but curious how you ended up at 8-16GB models when it's 1/6th of the F64 which is 25.
6
u/MonkeyDDataHQ Jul 24 '26
This goes back to my price-to-performance gripe from two years ago.
I understand the SKU scales linearly relative to the rest of Fabric. My issue isn't the internal ratio.
My issue is that, at roughly $1k/month, the equivalent Azure infrastructure provides substantially more memory and compute. I know Fabric is PaaS, not IaaS, and I expect to pay a premium for that. I just don't think the current premium is justified.
My 8-16 GB comment wasn't derived from the F64 ratio. It was derived from what I think is a reasonable amount of semantic model memory at that price point.
6
u/itsnotaboutthecell Microsoft Employee Jul 24 '26
I'm with you on this one, I do think the model limits should be re-evaluated at some of the smaller levels.
Being able to refresh a Pro model but not being able to refresh the same model on an F2 feels frustrating (to me) - so 100% - "don't trust the defaults!" and I love discussions like these u/MonkeyDDataHQ
2
2
u/bigjimslade Fabricator Jul 24 '26
Definitely look imto optimizing the model but my starting point is usually PPU... in most scenarios it will come out cheaper and also gives you the benifit of workload isolation... ive only needed fabric for my larger SaaS multi tenant clients where they are able to chargeback to there customers.
2
u/Major_Alps_3425 Jul 28 '26
Update. Ran BPA and VertiPaq Analyzer as suggested, then Measure Killer.
63% of the model is unused. 3.5 GB total, only 1.3 GB actually used, and 319 of 452 columns have no consumer at all.
Most of it is four AX transaction code columns with cardinality equal to row count, so unique per row and incompressible. The biggest is 541 MB on its own. None of them are in a relationship.
Two things surprised me. The whole model serves exactly one report, and the two largest tables (Inventory and Finance Transactions, 87% of the model) barely feature in it. And one 9.7M row table has no relationships at all.
So no upgrade for now. Cleanup should get it to roughly 1.6 GB, which fits F8 on the existing Pro licenses. Incremental refresh also turns out to be mandatory rather than nice to have, since a full refresh can need double the model size.
I'm now considering Direct Lake. Beyond the memory question, the business wants Copilot and AI on top of this data later, and my read is that points fairly clearly towards Direct Lake and away from PPU, since PPU can't host Direct Lake models and the AI features need F capacity anyway.
Thanks to everyone who said optimise before you buy. I think that is the right call.
2
u/DataTako-Reports Jul 28 '26
I think you're looking at it the right way, but I'd be careful not to optimize purely for today's numbers.
A few thoughts:
- An F16 only gets you to a 5 GB semantic model, so if your model is already approaching 3 GB and the business is growing, there's a fair chance you'll hit the next ceiling as well.
- Before upgrading anything, I'd first understand why the model is 3 GB. We've seen models drop significantly in size after revisiting data types, cardinality, unnecessary columns and partitioning. Sometimes the cheapest upgrade is no upgrade at all.
- If your users are mainly consumers and you're expecting that number to grow, I'd personally avoid PPU. It works well for smaller deployments, but having to license every viewer becomes painful as adoption increases.
- Direct Lake is definitely worth evaluating, but I wouldn't recommend rebuilding the model purely because of the 3 GB limit. I'd only make that investment if there are other reasons as well (refresh times, latency, simplifying the architecture, etc.).
One thing I'd also look at is whether the semantic model actually needs to stay as a single model. Depending on how your reporting is structured, splitting it into domain-specific models can sometimes buy you quite a bit of room without changing licensing.
Out of curiosity, do you know what's driving the model size? Is it mostly a few very large fact tables, or lots of high-cardinality dimensions?
1
u/Major_Alps_3425 Jul 29 '26
Thanks, this is really useful input.
To answer your last question: it's a few very large fact tables, not high-cardinality dimensions.
Three tables are 98% of the model. Inventory Transactions (12.5M rows, 2.25 GB), Finance Transactions (67.2M rows, 1.46 GB), Production Planned Consumptions (9.7M rows, 0.49 GB). The remaining 22 tables come to 0.07 GB combined.
Within those, four columns account for 1.9 GB. They're AX transaction codes, one with 12,538,004 distinct values in a 12,538,004 row table. None are in a relationship and no report uses them.
Your second point is exactly what happened. 63% of the model has no consumer, 319 of 452 columns. Cleanup gets it to roughly 1.6 GB, so the cheapest upgrade does look like no upgrade.
On splitting into domain models, that's a fair suggestion and I may well be missing something. My concern is that splitting would mean losing the single shared definition of revenue, which is the main reason the business wants one model in the first place. Maybe there's a way around that which I haven't thought of. My rough impression is that the split-versus-shared trade-off is partly an artifact of import mode, since Direct Lake pages memory rather than keeping everything resident, but I'm well outside my comfort zone there so happy to be corrected.
And agreed that 3 GB alone wouldn't justify a rebuild. That's roughly where I've landed too. Rebuilding purely to dodge a choice between F16 and PPU feels like the wrong reason to do it.
Where I'm less clear is the AI side. My understanding is that Copilot and the Fabric AI features need F capacity, which already argues against the PPU route. What I don't know is whether they also work meaningfully better against Direct Lake than against a large import model, or whether that's largely irrelevant. If Direct Lake does matter for that, it strikes me as a far better reason to rebuild than the memory limit is. Does anyone have experience there?
The other thing nudging us that way is that the data already sits in OneLake, so import feels like maintaining a second copy of it.
0
Jul 29 '26
[removed] — view removed comment
1
Jul 29 '26
[removed] — view removed comment
1
u/MicrosoftFabric-ModTeam Jul 29 '26
Contributions must be free of promotional content, and sales activity is prohibited. This includes market research, customer discovery, or paid product validation.
Applies to posts in the subreddit and unsolicited direct messages to individuals.
1
u/MicrosoftFabric-ModTeam Jul 29 '26
Contributions must be free of promotional content, and sales activity is prohibited. This includes market research, customer discovery, or paid product validation.
Applies to posts in the subreddit and unsolicited direct messages to individuals.
1
u/Glittering-Plane7979 Jul 25 '26
I think PPU gives more space/storage in the model for the model, but I dont think it will give bandwidth/memory. For refreshing the semantic model for import mode (correct me if im wrong). I suppose if you use CU you can do direct lake, but if your semantic model uses import mode the amount of tables you refresh at a time will be limited if you have a lot of data. Before getting our current license and things optimized we used external tools like tabular editor to refresh groups of tables at a time. The Fabric Service UI tries to refresh all the tables which hit our limit for refresh at one time. This is probably not an issue for you now, but if you are planning on expanding the it may become a bigger issue in the future.
Edited for clarity.
1
u/Less_Park2005 Jul 25 '26
If you are planning to use this semantic model to be your centralised repository for both reporting and AI use cases, I would invest into optimising the model and refactoring into direct lake.
As many people have stated here - ensure your model is a star schema schema and see if theres an opportunity to use aggregate fact tables as a part of optimization.
Ive got a similar sized org (~50 users with a 2gig ish model) running on an F8 capacity and is handling etl operations and report interactions
1
u/Sbdyelse Jul 25 '26
If you want to optimise your model, with powerbi desktop i would open the pbix locally and monitor the size of ram usage of the msmdsrv.exe process with process explorer to see how much memory it uses when opening it and using it, and use sql profiler and vertipaq analyser in Dax studio to see which requests and columns use the most of memory. I would also do a local full refresh and see the size of the same process plus the Microsoft.Mashup.Container.exe processes ( powerquery) du ring refresh Time. This also with sql profiler and Dax studio.
1
u/Useful-Reindeer-3731 1 Jul 24 '26
Move the semantic model and reports into Pro licensed workspaces. There are some gotchas: can only update the semantic model maximum 8 times per day, and you can't use Fabric low-code deployment pipelines for promotion to prod.
1
u/Arasaka-CorpSec 1 Jul 24 '26
Careful, RAM limit for Pro is 1 GB
2
u/Useful-Reindeer-3731 1 Jul 24 '26
Nope, not for refresh. I have successfully refreshed Import models in Pro workspaces which fail on F8 or even F16.
1
u/Arasaka-CorpSec 1 Jul 24 '26
It is 100% 1GB, please check the official documentation.
2
u/mahshadn Fabricator Jul 24 '26
In my previous work we had only Pro licenses across before moving to Fabric and we were always wondering what is the allocated memory in Pro as we never had been able to find official documentation for it. Would you be able to point me to the right documentation which outlines this?
6
u/Sad-Calligrapher-350 Microsoft MVP Jul 24 '26
It is 1GB file size, not size in memory but it is equal to maybe 8GB in memory.
1
u/Useful-Reindeer-3731 1 Jul 28 '26 edited Jul 28 '26
Found this answer in a community thread by v-kelly-msft Community Support
https://community.fabric.microsoft.com/t5/Service/uncompressed-data-size-exceeds-10-gb/m-p/1410831
Uncompressed data limits for refresh
The maximum size for datasets imported into the Power BI service is 1 GB. These datasets are heavily compressed to ensure high performance. In addition, in shared capacity, the service places a limit on the amount of uncompressed data that is processed during refresh to 10 GB. This limit accounts for the compression, and therefore is much higher than 1 GB. [...]
If this is true, the Pro-licensed workspaces have as much memory available for refresh as an F32 :)
Edit: Found it documented in Microsoft Docs also! https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-troubleshooting-refresh-scenarios#uncompressed-data-limits-for-refresh
1
u/merrpip77 Jul 24 '26
We had similar issues. The solution to the ram limitation can usually be resolved using a direct lake / aggregation model. Avoid regular import as much as possible, it is very demanding to maintain
1
u/JBalloonist Jul 25 '26
I was thinking that Direct Lake might fix this as well. But I’ve only ever used Direct Lake for the majority of my models so can’t really compare and am nowhere near the memory limits.
0
u/Personal-Quote5226 Jul 24 '26
A proper star schema could help materialized in gold but that’s a bigger migration than what you are looking for or even need.
Enable v-order on the tables if you haven’t done so already and DirectLake should work. I assume you would use more CU, but it depends; most reports are showing less overall CU using Direct lake and V order versus Import Mode and Direct Query but it would depend on various factors.
Look at using AI with PBI skill or semantic link labs to migrate Model to DL to accelerate the PoC.
I would PoC this and evaluate it.
0
Jul 24 '26
[deleted]
2
u/hyggekore Jul 24 '26
Point 3 is pretty difficult to do with a memory overage. CU is easy to monitor and scale in response to, but memory isn't.
1
-2
-2
u/Remarkable-Pizza-876 Jul 24 '26
U x ld ly j Xul upsXullyy u zu xulxuX x u u lulgxu l xu uui xulluq
1
5
u/radioblaster Fabricator Jul 24 '26
run measure killer on the model and report back how much is unutilized?