Power BI semantic model size limits: Pro 1 GB, PPU 100 GB, Fabric by SKU
A Power BI semantic model published to a Pro workspace can hold up to 1 GB of compressed data, a model in a Premium Per User (PPU) workspace can reach 100 GB, and a model on a Microsoft Fabric capacity is bounded by the memory of the F SKU, from 3 GB on F2 up to 400 GB on F1024 and above. Those are the figures Microsoft lists in its Power BI service description, its pricing page and its Fabric capacity documentation, all checked on November 13, 2026.
The three numbers look simple, but each one comes with conditions that decide whether a model refreshes reliably. Microsoft describes the capacity figures as an upper bound and says memory must be reserved for refreshes and queries, so the largest model that works in practice is smaller than the table value. A separate setting, the large semantic model storage format, decides whether a capacity model can grow past a lower per-SKU ceiling at all. Power BI Desktop uploads are capped at 10 GB whatever license is used.
For a BI lead, the practical question is which license or capacity a given model needs today and how long it will fit as data grows. The figures below come from Microsoft's documentation, and the sizing example at the end applies them to two illustrative models.
··········
POWER BI MODEL SIZE LIMIT BY LICENSE: PRO, PPU AND CAPACITY.
Microsoft's Power BI service description compares the three ways to license Power BI workloads with the same three rows: model size limit, refresh rate and storage. The Power BI pricing page repeats the 1 GB and 100 GB model limits and lists Pro at $14.00 per user per month and Premium Per User at $24.00 per user per month, both paid yearly, as shown on November 13, 2026.
........
License | Model size limit | Scheduled refreshes | Max storage | Listed price |
Power BI Pro | 1 GB | 8 per day | 10 GB per user | $14.00 user/month, paid yearly |
Premium Per User | 100 GB | 48 per day | 100 TB | $24.00 user/month, paid yearly |
Premium or Fabric capacity | Varies by SKU | 48 per day | 100 TB | Variable, by capacity |
........
The pricing page adds that users who already hold Pro, Microsoft 365 E5 or Office 365 E5 licenses can add Premium Per User for $14.00 per user per month, billed yearly. It also says the 100 TB native storage cap applies to all Pro, PPU and Fabric workspaces combined.
The PPU documentation uses the same caution as the capacity tables. Its footnote says the 100 GB figure "represents an upper bound for the semantic model size" and that memory must be reserved for refreshes and queries. PPU also runs on shared capacity across the organization and does not provision a Fabric capacity, so a PPU license gives Premium model sizes for Power BI items without lakehouses, warehouses or notebooks.
··········
FABRIC CAPACITY MEMORY LIMITS FOR SEMANTIC MODELS BY F SKU.
On Fabric and Premium capacities, the documented limit is the "Max memory (GB)" column of Microsoft's semantic model limits table. Microsoft states that this column is an upper bound for the semantic model size and that "the maximum semantic model size permitted on a capacity might be smaller than the numbers in this column." The table below lists the F SKUs from F2 to F256 with their Power BI equivalents, as published in the Fabric documentation last updated in June 2026.
........
Fabric SKU | Power BI equivalent | Max memory (GB) | Small format ceiling | Max memory per query (GB) |
F2 | none | 3 | 1 GB | 1 |
F4 | none | 3 | 2 GB | 1 |
F8 | EM1/A1 | 3 | 3 GB | 1 |
F16 | EM2/A2 | 5 | 5 GB | 2 |
F32 | EM3/A3 | 10 | 6 GB | 5 |
F64 | P1/A4 | 25 | 10 GB | 10 |
F128 | P2/A5 | 50 | 10 GB | 10 |
F256 | P3/A6 | 100 | 10 GB | 10 |
........
Larger SKUs continue the pattern: F512 lists 200 GB of max memory, and F1024, F2048, F4096 and F8192 each list 400 GB. Microsoft notes that F512 and above are not available in all regions. Fabric trial capacities are assigned an F4 or F64 SKU and inherit that SKU's limits for the duration of the trial.
The SKU also decides who can open the reports. On F SKUs smaller than F64, every user viewing Power BI content needs a Pro or PPU license or an individual trial; on F64 or larger, users with a free license and a viewer role can view content. That licensing rule often weighs more than memory when a team chooses between PPU and a capacity, a trade-off covered in our comparison of Power BI Pro, Premium Per User and Fabric F64.
··········
LARGE SEMANTIC MODEL STORAGE FORMAT AND THE SMALL FORMAT CEILING.
The "Small format ceiling" column above is the hard limit Microsoft sets on the Max Offline Semantic Model Size workload setting for models in the default small storage format. It is measured as the compressed size on disk. On an F64 or P1 capacity, a small-format model stops at 10 GB even though the SKU has 25 GB of memory, and on F2 the ceiling is 1 GB.
Microsoft's documentation says this per-SKU ceiling does not apply to models stored in the large semantic model storage format. With the large format, the size limit equals the capacity size or the maximum set by the capacity administrator. The setting can be enabled on all Fabric F SKUs, Premium P SKUs, Embedded A SKUs, PPU workspaces and Pro workspaces assigned to Reserved Capacity for Pro Workspaces, where the limit stays at 1 GB.
An administrator or model owner turns the format on in the semantic model settings, or sets it as the default storage format in the workspace Premium settings so new models use it. Existing models can also be switched with the Set-PowerBIDataset PowerShell cmdlet and the PremiumFiles target storage mode, which requires capacity admin and workspace admin rights. Microsoft lists several constraints for the large format:
........
Large format condition | What Microsoft documents |
Regions | Azure regions that support Azure Premium Files storage |
Region moves | The workspace cannot move to a capacity in another region |
Push semantic models | Not supported |
Desktop upload | Still limited to 10 GB; the model grows in the service on refresh |
Default segment size | 8 million rows |
........
Because of the 10 GB upload cap, Microsoft describes large models as growing beyond that size in the service on refresh after publication, and fine-grained refreshes through the enhanced refresh REST API or the XMLA endpoint reduce the memory a single refresh needs.
··········
REFRESH MEMORY: WHY A MODEL NEEDS HEADROOM ON THE CAPACITY.
Refreshes and queries need working memory on top of the model itself, which is why Microsoft presents the documented maximum as an upper bound. Microsoft's large-model guidance gives a concrete rule: semantic models "that are close to half the size of the capacity size (for example, a 12-GB semantic model on a 25-GB capacity size) may exceed the available memory during refreshes." Sizing a capacity so the largest model stays at or below half of the SKU's max memory is therefore the conservative reading of the documentation.
Query memory is a separate limit. An F64 allows 10 GB of memory per query and an F2 allows 1 GB, and the Query Memory Limit workload setting defaults to an automatic SKU-specific value. A model that fits in memory can still fail on a heavy DAX query if that query needs more than its per-query allowance. Admins configure these values under OneLake catalog, Govern, Capacities, in the Workloads section of the Power BI Premium tab.
Direct Lake models on Fabric follow their own guardrails. The same limits table lists 300 million rows per table and a 10 GB maximum Direct Lake model size on OneLake for F2 to F8, with 1,500 million rows per table and no model size cap from F64 upward. When a Direct Lake model exceeds these guardrails, queries fall back to DirectQuery. Teams that also plan Copilot or data agents on the same capacity can compare these sizes with the capacity requirements in our Copilot in Power BI requirements reference.
··········
POWER BI SIZING EXAMPLE: PRO, PPU OR AN F SKU FOR TWO MODELS.
The following example is illustrative. The model sizes, growth rates and team size are assumptions; the limits and per-user prices are the ones Microsoft lists, and the arithmetic was computed in Python.
Model A is a marketing model of 0.80 GB in a Pro workspace that grows by about 0.03 GB per month. Model B is a sales model of 6 GB used by 30 people, growing by about 0.25 GB per month.
........
Check | Model A (0.80 GB) | Model B (6 GB) |
Fits Pro 1 GB limit | Yes, for about 6 months | No |
Fits PPU 100 GB limit | Yes | Yes |
Smallest F SKU at half of max memory | F2 (3 GB) | F64 (25 GB) |
Small format ceiling on that SKU | 1 GB | 10 GB |
Months of growth before half of F64 | not needed | 26 |
........
Model A reaches the 1 GB Pro limit after about 6.7 months at its current growth, so the team has two quarters to either reduce the model or move it. Microsoft's data reduction guidance for import models lists techniques such as removing unnecessary columns and rows, grouping and summarizing, optimizing column data types and disabling auto date/time, and for a model this close to the limit they can postpone a license change.
Model B rules out Pro. Under the half-of-memory rule it needs at least 12 GB of capacity memory, which excludes F32 with its 10 GB, even though F32's 6 GB small-format ceiling would technically accept the file. The smallest F SKU that leaves refresh headroom is F64 with 25 GB, and at 0.25 GB of growth per month the model reaches 12.5 GB, half of F64, after 26 months. On F64, users with a free license and a viewer role can open the reports, while publishers still need Pro, so the capacity has to be compared with per-user licensing. Thirty PPU licenses at $24.00 cost $720 per month, or $8,640 per year at the listed price; if all 30 users already hold Pro or an E5 license, the $14.00 add-on brings that to $420 per month, or $5,040 per year. Fabric capacity prices were not displayed on Microsoft's Azure pricing page when it was checked for this piece, so the F64 side of the comparison has to be priced for the buyer's region in the Azure pricing calculator.
The same example in pandas lets a team replace the assumptions with its own model sizes:
import pandas as pd
max_memory_gb = {"F2": 3, "F4": 3, "F8": 3, "F16": 5, "F32": 10, "F64": 25, "F128": 50, "F256": 100}
models = pd.DataFrame({
"model": ["A", "B"],
"size_gb": [0.80, 6.0],
"growth_gb_per_month": [0.03, 0.25],
})
def smallest_sku(size_gb):
for sku, mem in max_memory_gb.items():
if mem >= 2 * size_gb:
return sku
return None
models["fits_pro"] = models["size_gb"] <= 1.0
models["months_to_pro_limit"] = ((1.0 - models["size_gb"]) / models["growth_gb_per_month"]).clip(lower=0).round(1)
models["smallest_f_sku"] = models["size_gb"].apply(smallest_sku)
print(models)The size to enter is the size of the published model in the service, which can differ from the PBIX file on a developer's machine. Teams that prepare data in Power Query before it reaches the model can cut that size early; our guide on writing Power Query M with Claude covers type and null checks that also keep columns lean.
··········
POWER BI MODEL SIZE LIMITS: WHAT TO CHECK IN YOUR TENANT.
Microsoft documents three fixed numbers: 1 GB per model on Pro, 100 GB on Premium Per User and a 10 GB upload limit from Power BI Desktop. On Fabric and Premium capacities the limit depends on the SKU's max memory, from 3 GB on F2 to 400 GB on F1024 and above, and on whether the model uses the large semantic model storage format, without which a capacity model is capped at the small-format ceiling of 1 GB to 10 GB.
What depends on the tenant is the setting layer: a capacity administrator can lower the maximum through the Max Offline Semantic Model Size workload setting, the large format must be enabled per model or per workspace, and the format is limited to regions that support Azure Premium Files storage. Microsoft's own documentation also disagrees on PPU refreshes, listing 48 per day in its comparison table while another line on the same page says the number of refreshes is not restricted.
Microsoft does not publish a single safe model size per SKU. Its guidance points to keeping a model near or below half of the capacity memory to protect refreshes, and the Fabric Capacity Metrics app does not currently expose the memory limits in the table, so teams with growing models should track model size in the service and plan the next SKU or the large format before a refresh fails.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
