Power BI Desktop

[MLBLom]

We are receiving the following error when attempting to publish a PBIX file from Power BI Desktop to either a Pro workspace or a Fabric F2‑backed workspace:

Power BI Premium backend error
Failed to PublishABf database: unable to load the dataset: its size of 1029 MB exceeds the limit of 1024 MB.

What are the recommended options for resolving this issue?

Specifically:

• Would upgrading to a higher Fabric capacity (such as F4 or higher) resolve the publish size limitation?
• If moving to an F4 capacity, is a capacity upgrade alone sufficient to publish a PBIX file larger than 1024 MB, or would we also need to change the architecture (for example, by using OneLake / Direct Lake or another approach)?

Any guidance on best practices for handling datasets of this size would be appreciated.

[cengizhanarslan]

Upgrading to F4 capacity will raise the 1 GB publish limit and likely unblock your immediate issue, but F4 still has a size ceiling:

A capacity upgrade alone may be sufficient short-term, but at 1 GB your model almost certainly has optimization opportunities: unused columns, high-cardinality text fields, or heavy Power Query transformations that should be moved upstream to SQL or a Fabric Lakehouse.

[krishnakanth240]

Hi @MLBLom 

Yes, moving from F2 to F4+ will remove the 1 GB publish limit if the workspace is assigned to that capacity.

Capacity upgrade alone is sufficient to publish >1 GB Pbix and no architecture change required.

However, it is recommended to use large dataset storage format and optimized data model as a best practice. As a best practice, you can optimize model by removing unused columns, disabling auto date/time and using aggregations which often reduces size 30–70%

[Natarajan_M]

Hi @MLBLom , What you are facing is the pbi constrains in pro and F2 capacity
Max Model Size Limits

Power BI Pro: 1 GB
Fabric F2 Capacity: ~3 GB (based on available memory)

Recommendation
To successfully publish your 1,029 MB model, reduce the model size below 1 GB before uploading by:

Removing unused columns and tables
Filtering out unnecessary historical rows
Using numeric keys instead of high-cardinality text columns

Once published, you can trigger a scheduled or manual refresh in the Power BI Service — semantic models can grow beyond the default size limit in the service on refresh when the Large Semantic Model Storage Format is enabled on a Fabric capacity workspace.

https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-large-models


thanks 
If you found this helpful, please consider giving it a kudo and marking it as the accepted solution — it goes a long way in helping others facing the same issue.

For more Power BI tips and discussions, let’s connect on LinkedIn:
https://www.linkedin.com/in/natarajan-manivasagan

Cheers!

[Lodha_Jaydeep · Accepted solution]

Hi @MLBLom,

This issue is expected behavior due to the 1 GB dataset size limit in Power BI Pro workspaces. Since your dataset is 1029 MB, it slightly exceeds the allowed limit, which is why the publish is failing.

Key Points:

• Power BI Pro / F2 capacity → Max dataset size: 1 GB
• Your dataset: 1029 MB → exceeds limit

Answers to your questions:

1. Will upgrading to F4 (or higher) resolve this?
   Yes. Moving to a higher Microsoft Fabric capacity like F4 or above increases the dataset size limits (typically up to several GBs depending on capacity). This alone can allow your PBIX to be published successfully.
2. Is capacity upgrade alone sufficient?
   Short answer: Yes, but not always optimal.

• Yes – upgrading capacity will allow publishing larger PBIX files.
• However, for datasets already crossing 1 GB, it’s strongly recommended to optimize the model or adopt a better architecture, because:
• Larger datasets impact refresh performance
• Memory pressure can affect capacity performance
• Scaling costs increase over time
  
  

Recommended Best Practices:

Instead of relying only on capacity upgrade, consider:

1. Optimize your dataset

• Remove unused columns
• Reduce cardinality (avoid high-cardinality text fields)
• Use aggregations where possible
• Disable auto date/time
  
  

1. Use Direct Lake / OneLake architecture

• Store data in OneLake
• Use Direct Lake mode to avoid importing large datasets into memory
  
  

1. Switch to DirectQuery (if applicable)

• Keeps dataset small but may impact performance depending on source
  
  

1. Incremental Refresh

• Only refresh recent data instead of full dataset
  
  

1. Composite models

• Combine Import + DirectQuery strategically
  
  

Recommendation:

If this is a quick fix → Upgrade to F4
If this is a long-term solution → Combine capacity upgrade + model optimization or Direct Lake approach

Hope this helps!
Kudos are appreciated if you find this useful, and feel free to mark it as the accepted solution.