Forum Discussion
Capacity Throttling
In Fabric/Power BI, a workspace is assigned to exactly one capacity at a time. So “two capacities” really means: two sets of workspaces, each mapped to a different capacity.
1) Buy / provision a second capacity
You’ll need:
Capacity A (existing): e.g., F16
Capacity B (new): e.g., F4/F8 (often enough for pipelines)
2) Split by workspace (the only supported way)
Create two workspace groups:
A) “Data Engineering” workspace(s) → Capacity B
Put pipelines / ingestion / staging here:
Data pipelines that load from Dataverse
Lakehouses / Warehouses used for staging and transformations
Scheduled jobs
Assign these workspaces to Capacity B.
B) “BI / Consumption” workspace(s) → Capacity A (F16)
Put user workloads here:
Semantic models
Reports
Paginated reports
Apps
Assign these workspaces to Capacity A.
Hi Hussein_charif,
There are two options to resolve this:
1: Optimize the reports/semantic models so they are more efficient and use less capacity, or2: get a bigger capacity.
It is very common for the Fabric ETL pipelines to be on a different capacity than the end user reports so that end users can't cause the ETL to fail.
What I would do:
1: create a new workspace for the Power BI reports
2: move all reports into that new workspace
3: Either optimize the reports, or purchase a second capacity, and assign the report workspace to the new capacity.
1) Separate “daytime BI” from “back-end pipelines” (biggest win)
If your pipelines are near real-time, they’re constantly consuming capacity in the background. When users then run paginated exports, you get contention.
Best practice is to put these on different capacities if possible:
Capacity A: Data Engineering / pipelines / refresh
Capacity B: BI consumption / paginated exports
Even a smaller F-SKU for pipelines can stabilize the user-facing F16 dramatically.
2) Control paginated export concurrency / behavior
Encourage users to export from a filtered view (not “all data”)
Avoid huge tablix detail exports; consider summary-first layouts
For repeated needs, use subscriptions or Power Automate so exports run on schedule rather than ad-hoc bursts
If the same paginated report is repeatedly run with the same parameters, consider caching patterns (where applicable)
Also check whether they’re exporting PDF/Excel with a lot of pages—that is significantly heavier than small extracts.
3) Stagger and/or reduce refresh pressure
Near real-time incremental loads + daily 1.5M rows can be fine, but three pipelines continuously running can keep the capacity “warm” all day.
Reduce frequency if truly “near real-time” isn’t required (e.g., every 15 min vs every 2–5 min)
Batch changes (micro-batch) rather than constant processing
Ensure staging → fact merge is optimized (partitioning, incremental updates, avoid full table scans)
If you have a daily peak period for exports, avoid running heavy pipeline steps during that window.
4) Optimize the semantic model + paginated reports (reduce CPU/memory per export)
4.1 Use the right connection type for paginated reports
Paginated → Semantic model
Pros: reusable business logic, security (RLS), consistent metrics
Cons: exports can be heavy because each run triggers DAX query execution + rendering, often more expensive on capacity when the model is large/complex.
Paginated → SQL endpoint / Warehouse / Lakehouse SQL
Pros: can be more predictable for large “table exports” (simple SELECTs), pushes work to the SQL engine
Cons: you must manage security there (or mirror RLS logic), and you may lose measure logic unless you rebuild it in SQL/views.
Rule of thumb:
If paginated is mainly detail table extracts (many rows/columns) → SQL endpoint often scales better.
If paginated is pixel-perfect with semantic measures → semantic model is fine, but must be optimized.
4.2 Reduce “export cost” by shaping paginated output
Avoid huge detail tablix with thousands of rows and complex expressions.
Require parameters (Date range, Business unit) and set sensible defaults.
Turn off expensive features unless needed (interactive sorting, complex grouping, nested tablix).
4.3 Optimize the semantic model for paginated/export workload
Reduce cardinality: replace text keys with integers, remove high-cardinality text columns from fact.
Prefer star schema (dimension filters → fact), avoid many-to-many where possible.
Reduce measure cost:
Avoid iterators (SUMX) over large tables when a native aggregation works
Be careful with DISTINCTCOUNT on huge columns; consider alternatives (or aggregations)
Use aggregations / composite model if you have very large facts and repeated patterns.
Ensure incremental refresh partitions are correct and not forcing large scans.
If many exports hit the same visuals/queries, consider cache warming patterns (scheduled query hits), so exports don’t always pay full cold-start cost.
Disclosure:
This response was written based on my own professional experience and understanding of Microsoft Fabric. AI-based tools were used solely as a supporting aid for wording and structure refinement. All technical interpretations, validations, and conclusions are my own responsibility.
hello cengizhanarslan ,
can you please elaborate on how i can have 2 capacities and split my workloads on each seperately?
In Fabric/Power BI, a workspace is assigned to exactly one capacity at a time. So “two capacities” really means: two sets of workspaces, each mapped to a different capacity.
1) Buy / provision a second capacity
You’ll need:
Capacity A (existing): e.g., F16
Capacity B (new): e.g., F4/F8 (often enough for pipelines)
2) Split by workspace (the only supported way)
Create two workspace groups:
A) “Data Engineering” workspace(s) → Capacity B
Put pipelines / ingestion / staging here:
Data pipelines that load from Dataverse
Lakehouses / Warehouses used for staging and transformations
Scheduled jobs
Assign these workspaces to Capacity B.
B) “BI / Consumption” workspace(s) → Capacity A (F16)
Put user workloads here:
Semantic models
Reports
Paginated reports
Apps
Assign these workspaces to Capacity A.