Forum Discussion
Why does PBI Service show different Semantic Model storage sizes when VertiPaq memory size is
Hi Georma from what I have seen
You can inspect things like partitions, model metadata, and object definitions using tabular Editor, but i dont thi k anything takes you perfectly to the system vakue storage. I think microsoft ticket will help with this. Do keep us posted
Hi Georma
System Storage is not the same thing as VertiPaq memory.
What System Storage is measuring
In Power BI Service, System Storage is the amount of workspace storage consumed by the semantic model item in the service. It is a service-side storage/accounting number, not the VertiPaq Analyzer number you see in DAX Studio.
So when you see:
- VertiPaq size ~3.65 GB in both models
- but System Storage ~1.7 GB vs ~3.6 GB
that means Power BI Service is counting more than just the compressed column store for one model, or it is accounting for the model differently in the service.
What can be included besides VertiPaq
Microsoft doesn’t publicly give a super-detailed byte-for-byte breakdown, but in practice the storage footprint can include things like:
- Model metadata
- tables, columns, relationships
- measures, calculation groups
- hierarchies, perspectives, translations
- annotations, display folders, formatting, roles
- Partitions
- especially if the model has many partitions
- incremental refresh can create multiple partitions
- Power Query / M metadata
- query definitions are stored with the model
- source/lineage metadata may differ by design
- Refresh policy / incremental refresh configuration
- Service-managed item overhead
- internal metadata the service keeps for the semantic model
- possible versioning/snapshot-related overhead around refresh and publish operations
Can model-building differences affect System Storage?
Yes — indirectly.
Even if VertiPaq memory is the same, the way the model is built can still affect service storage through:
- number of partitions
- incremental refresh setup
- query and refresh metadata
- model object complexity
- service-generated internal metadata
That said, if the VertiPaq footprint is essentially identical, then a 2x difference in System Storage is usually not explained by M vs SQL transformations alone. It more often points to one of these:
- Different partition structures
- Different incremental refresh or refresh history behavior
- Different service-side metadata overhead
- A storage accounting quirk or caching/compaction artifact in the service
- Different hidden model objects such as roles, translations, relationships, calc groups, or annotations
Practical interpretation for your case
Given your description, the most likely conclusion is:
- VertiPaq Analyzer is telling the truth about model data size
- System Storage is reflecting the total service storage footprint
- the difference is probably due to non-data overhead, not the main fact table or business logic itself
Why the Redshift/Power Query model might look smaller in System Storage
One plausible explanation is that the model built more in Power Query may have:
- fewer or simpler service-managed partitions
- different refresh metadata
- less internal overhead from how the model was authored or published
Meanwhile, the SQL-first model may have:
- more partitions
- more complex source metadata
- more service-side bookkeeping
Bottom line
- System Storage ≠ VertiPaq memory
- It measures the semantic model’s storage footprint in the service, including more than the in-memory column store
- Yes, metadata, partitions, M queries, refresh policies, and service-generated overhead can all contribute
- If two models have the same VertiPaq size but different System Storage, the difference is usually in service overhead / metadata / partitioning, not the raw compressed data
Thank you for the explanation. I understand the difference between VertiPaq memory and System Storage.
However, my main question is what is actually consuming the additional 2 GB of System Storage.
I have already verified that:
- Both models have virtually the same VertiPaq size (3.64 GB vs. 3.65 GB).
- Both are in the same Premium capacity.
- Both use the Large semantic model storage format.
- Both are hosted in the same region.
- Republishing the model results in the same System Storage size.
Is there any way to break down the System Storage footprint to understand what is consuming the additional space?
For example, is there any tool, API, or administrative view that exposes how the Semantic Model storage is distributed (partitions, metadata, snapshots, service-managed objects, etc.)?
I would like to identify the specific component responsible for the storage difference rather than just knowing that System Storage includes more than the VertiPaq model.
Hi Georma from what I have seen
You can inspect things like partitions, model metadata, and object definitions using tabular Editor, but i dont thi k anything takes you perfectly to the system vakue storage. I think microsoft ticket will help with this. Do keep us posted
There is no official Power BI Service view or API that gives a full byte-by-byte breakdown of “System Storage” for a semantic model.
What you can do is inspect the model through the XMLA endpoint and use DMVs to understand what is taking space inside the model:
- table / column storage
- dictionaries and segments
- partitions
- metadata objects such as roles, relationships, measures, annotations, and hierarchies
Microsoft documents the XMLA endpoint and large semantic model behavior here:
What System Storage is likely including
System Storage is a service-level storage accounting measure, not just VertiPaq column-store memory. It can reflect:
- persisted semantic model data
- model metadata
- partition metadata
- refresh / incremental refresh artifacts
- service-managed overhead
Microsoft’s docs on enhanced metadata and incremental refresh are relevant here:
What you can inspect today
1) XMLA endpoint + DMVs
This is the best way to compare the two models. Use tools like:
- DAX Studio
- SSMS
- Tabular Editor
Microsoft’s XMLA endpoint documentation:
2) Things to compare
You can query DMVs to compare:
- partitions
- storage by table / column / segment
- measures
- relationships
- roles
- annotations
- hierarchies
That helps you find whether one model has more partitions, more metadata, or more service-generated structure.
3) Check model shape and refresh design
Differences in how the model is built can affect storage overhead indirectly, even if VertiPaq size is the same. For example:
- more partitions
- incremental refresh setup
- more model metadata
- more annotations or roles
- different query folding / table generation patterns
Microsoft’s large model and dataset mode docs are useful context:
What you cannot see directly
Microsoft does not provide a supported “System Storage breakdown” that says exactly:
- X GB = VertiPaq
- Y MB = metadata
- Z MB = snapshots
- etc.
So if the extra 2 GB is from service-managed overhead, you may be able to infer it from metadata and partition differences, but not read it as a dedicated line item.
Practical conclusion for your case
Given that:
- VertiPaq sizes are nearly identical
- both models are in the same capacity
- both use Large semantic model storage format
- republishing doesn’t change the result
the most likely explanation is non-VertiPaq service overhead, such as:
- partition structure
- incremental refresh artifacts
- metadata volume
- service-managed packaging/overhead
Most useful Microsoft docs
If you want to investigate further, start here: