If you’ve spent time in a Power BI semantic model’s settings, you’ve probably noticed the Large semantic model storage format toggle. Most people leave it off because they’re not entirely sure what it does or whether they actually need it.

This blogpost breaks down what large semantic model storage format is, what it requires and the practical implications for your environment, so you can make an informed decision rather than just leaving it on the default.

What Is the Large Semantic Model Storage Format?

By default, Power BI stores semantic models in a compressed in-memory format. This works well for most models, however, the entire semantic model must fit within the memory allocated to your capacity, and there is a hard limit on compressed model size, around 1GB.

Enabling large semantic model storage format switches the underlying storage to Azure Premium Files Storage, where data is persisted as VertiPaq-compressed segments. Instead of loading the whole model into memory at once, Power BI can page data in and out as needed. This is similar to how Analysis Services handles large tabular models on-premises.

With this enabled, the semantic model size limit is equal to the Fabric capacity size or the maximum size set by the capacity administrator, meaning they can get quite big if you want them to.

What Do You Need to Use It?

Large semantic model storage format is a Premium feature. It requires one of the following:

  • Power BI Premium Per Capacity (P1 or above)
  • Power BI Premium Per User (PPU)
  • Microsoft Fabric capacity (available on all F SKUs, though note that XMLA read/write access (covered below) requires F64 or above)

You also need to switch it on at two separate levels:

  • Tenant level: A Power BI admin must enable Large semantic models under Admin portal > Tenant settings.
  • Semantic model level: Within the individual semantic model’s settings in the Power BI Service, toggle on Large semantic model storage format.

The Large Semantic Model Format toggle in the settings of Power BI

 

When Should You Enable It?

There are three main scenarios where large semantic model storage format makes a meaningful difference.

1. Your model is approaching or exceeding memory limits

The most straightforward reason. If your semantic model is large (think hundreds of millions of rows, detailed transaction history, or wide fact tables) and you are hitting capacity memory limits or seeing refresh failures because the model is too big, large semantic model storage format is the right fix.

Without it, once the in-memory model exceeds available capacity memory, refresh will fail. With it, the model can extend beyond that boundary by paging out to storage.

2. You want to configure incremental refresh via the XMLA endpoint

If you want to manage incremental refresh programmatically via the XMLA endpoint, rather than through the Power BI Desktop UI, enabling large semantic model storage format is strongly recommended, even for models you wouldn’t consider large.

This matters if you’re handling partition management via Tabular Editor, a custom .NET application, a Logic App, or an Azure Function, selectively refreshing date-range partitions without triggering a full model refresh. The actual hard requirement for XMLA write operations is a Premium capacity with XMLA read/write enabled; however, large semantic model storage format meaningfully improves the performance and reliability of those write operations, and Microsoft explicitly recommends enabling it for any XMLA write scenario.

3. You’re doing any advanced XMLA write operations

More broadly, any scenario involving write operations via the XMLA endpoint, such as scripting partition management, updating model metadata, or processing individual tables, is better supported on large semantic model storage format. If you’re building a mature, programmatically managed Power BI estate, you’ll likely want this on.

What Are the Practical Implications?

Semantic model eviction still applies

Large semantic model storage format does not make your semantic model immune to eviction from memory when capacity is under pressure. What it does change is the reload behaviour: rather than requiring a full re-refresh from the source, the model is paged back in on-demand from Azure Premium Files Storage, where the data is persisted as VertiPaq-compressed segments. This means reports remain available after eviction, but there may be a noticeable cold-start latency on the next query while relevant pages are loaded back into memory.

Rolling back is not straightforward

Once a semantic model has been saved in large semantic model storage format, reverting it requires republishing from Power BI Desktop. There is no toggle-off and revert. Factor this into your change management process before enabling it on production-critical semantic models without testing first.

It does not fix slow queries

Large semantic model storage format is about model size and storage architecture. If your reports are slow due to inefficient DAX, poorly structured relationships, or too many visuals firing complex queries simultaneously, this setting will not help. Optimise the model first. This feature is for scale, not speed.

Do You Need It?

Decision guide:

Scenario Enable?
Model is a few GB and refreshes fine No
Hitting refresh failures due to model size Yes
Managing incremental refresh via XMLA Yes (strongly recommended)
Doing advanced XMLA partition scripting Yes
On shared capacity or Pro license No (won’t take effect)

If you’re working towards a more mature Power BI or Fabric setup and want help with capacity planning, semantic model architecture, or XMLA-based refresh strategies, please do get in touch with the Purple Frog team.

 

For further reading: Large semantic models in Power BI Premium – Microsoft Fabric | Microsoft Learn

 

 

Tags: , ,

« Previous Post
Next Post »