How does Power BI schedule refresh work when multiple reports use the same SQL tables and incrementa

[manoj_0911]

How does Power BI schedule refresh work when multiple reports use the same SQL tables and incremental refresh?

Hi Community,

I have published 20+ reports to the Power BI Service (Prod environment).
Most of these reports are configured with Incremental Refresh every 2 hours.

A few points about my setup:

• Some reports are built using the exact same SQL tables, but published as separate reports.

• Some reports point to the same fact and dimension tables.

• Some reports use database views in SQL.

• All of these reports are scheduled to refresh every 2 hours.

My main question:

If multiple datasets are scheduled to refresh at the same frequency and then:

1. Does Power BI trigger all those refresh queries at the same time?
2. Or does the service queue and stagger them automatically?
3. Will this create very high load on SQL Server if 10–20 datasets hit the same tables simultaneously?

I want to understand how the Power BI Service handles refresh load

Any guidance or best practices would be greatly appreciated!

Thanks.

[tayloramy · Accepted solution]

Hi @manoj_0911, 

If all the reports are using the exact same tables, you should make one semantic model and point all the reports at that same model, that way the data is only refreshed once. 

If each report has its own semantic model, and they are all set to refresh at the same time, they do refresh at the same time, potentially hitting the source system with the same queries 20 times. Depending on the size of your SQL Server instance, this could create a high load. 

[govind_021]

When multiple Power BI datasets are scheduled to refresh at the same frequency (for example, every 2 hours), Power BI Service attempts to start each refresh at its scheduled time. There is no built-in orchestration or automatic staggering across datasets.

If 10–20 datasets are scheduled for the same time, Power BI may initiate many refreshes in parallel, depending on available capacity. If service resources are constrained, some refreshes may start slightly later, but this delay is not guaranteed or predictable.

Even with Incremental Refresh, each dataset runs its own queries against the source for the required partitions. Power BI does not share cached results across datasets, even if they use the same SQL tables or views.

As a result, simultaneous refreshes can create significant load on SQL Server, especially when many datasets hit the same fact tables at once.

Best practices include staggering refresh times, optimizing SQL indexes/views, using incremental refresh correctly, and monitoring source load—especially in shared or Premium capacities.

Best Regards
Govind Sapkade ( Microsoft Certified Data Analyst , PL 300 Certified , MS Fabric Enthusiast)
Let's Connect
Linkdin - www.linkedin.com/in/govind-sapkade-845104225
Youtube - http://www.youtube.com/@govind_dataanalyst

[v-prasare]

Hi @manoj_0911,

We would like to confirm if our community members answer resolves your query or if you need further help. If you still have any questions or need more support, please feel free to let us know. We are happy to help you.

Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support

[v-prasare]

Hi @manoj_0911,

We would like to confirm if our community members answer resolves your query or if you need further help. If you still have any questions or need more support, please feel free to let us know. We are happy to help you.

Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support

[cengizhanarslan · Accepted solution]

1) Are all refreshes triggered at the same time?

Yes, potentially. Power BI Service uses a time window, not an exact queue. If you schedule 20 datasets for “every 2 hours”, many of them will start within the same few minutes.

2) Does Power BI queue or stagger them automatically?

Only partially, and only inside a capacity.

Power BI has two different throttling layers:

a) Capacity-level throttling (Fabric / Premium)

• Limits how many refreshes can run in parallel per capacity

• If the capacity is busy, some refreshes wait

b) Gateway-level throttling

• The on-prem gateway also limits concurrent queries

• But again, it’s generic — not table-aware

3) Will this overload SQL Server?

Common symptoms when many incremental refreshes collide:

• CPU spikes

• TempDB pressure

• Blocking (especially if ETL writes happen at the same time)

• Sessions getting killed (ties directly to your earlier SQL 596 issue)

• Refreshes randomly failing “sometimes but not always”

Incremental refresh reduces data volume, but:

• It still opens multiple SQL sessions

• Still scans partitions

• Still competes for locks, memory, and I/O

[tayloramy · Accepted solution]

Hi @manoj_0911, 

If all the reports are using the exact same tables, you should make one semantic model and point all the reports at that same model, that way the data is only refreshed once. 

If each report has its own semantic model, and they are all set to refresh at the same time, they do refresh at the same time, potentially hitting the source system with the same queries 20 times. Depending on the size of your SQL Server instance, this could create a high load.