Power BI report server

Hi gkc9​,

Yes, a scale-out behind a load balancer you manage is supported for Power BI Report Server, including the May 2026 release. The nodes share one report server catalog database, and Microsoft does not supply the load balancer itself; you add your own. For PBIX reports, client affinity (sticky sessions) on that load balancer is required, not optional. That is called out as an important note on the scale-out page.

1. How to stand it up. Install each extra node at the same PBIRS version as the first, connect it to the existing ReportServer database (not ReportServerTempDB), then join it on the Scale-out Deployment page in Report Server Configuration Manager. Use the same domain service account on every node, or grant each service account dbadmin on the SQL instance that hosts the catalog; otherwise subscription and SQL Agent edits fail when the balancer sends the request to a different node. On the balancer, put only the interactive nodes in the pool, use the virtual host name in each node's Hostname and UrlRoot in RSReportServer.config, and paste the same MachineKey into every node's RSReportServer.config so interactive HTML view state stays valid across nodes.
2. Licensing. PBIRS is licensed by cores, either with Fabric F64+ reserved instances or with SQL Server core licenses. On SQL Server 2025, you may run PBIRS on a maximum number of cores equal to the Standard or Enterprise core licenses assigned to the licensed server, with a minimum of four core licenses per operating system environment. For Enterprise editions released before 2025, the right applies only to Enterprise core licenses with active Software Assurance. Each added node is another environment, so it consumes cores against that cap (again with the four-core minimum). If you use Fabric, the get-started page says you may run PBIRS in a physical or virtual environment with up to the number of cores included under the F64+ reserved capacity; P SKUs also include PBIRS, EM SKUs do not. A Power BI Pro license is required to publish Power BI reports to PBIRS. Confirm the exact core count for your contract with your licensing source, because the public page states the cap and the minimum, not a worked example for a two-node farm.
3. Dedicating refresh. Yes. In each node's RSReportServer.config you can set IsDataModelRefreshService. Set it to False on the nodes that serve the morning user load, and True on one or more nodes that are not in the user load-balancer pool. Scheduled refresh events sit in a queue in the shared catalog database, and only the refresh-enabled nodes pick them up. That is the documented way to stop refresh and interactive PBIX rendering competing for CPU and memory on the same machine.
4. What still applies in scale-out. SSMS settings such as ScheduleRefreshTimeoutMinutes apply to every node. After a refresh, the data model can be replicated across nodes. Sticky sessions remain required for consistent PBIX behaviour. I could not find a Microsoft page that publishes required load-balancer health-check paths or timeout values, so treat those as your own: probe the virtual Web Service and Web Portal URLs, and size timeouts above your slowest acceptable report render.
5. How to tell whether the bottleneck is the report server node or the catalog database, before you scale out. Capacity planning guidance found CPU on the report server was the first resource to saturate, and it recommends putting the catalog database on a separate machine so it does not compete with PBIRS. Compare, over a morning peak:
   • On the PBIRS node: CPU, memory, and RSPowerBI_*.log (this is the log for scheduled PBIX refresh). Memory pressure during refresh is a known cause of failed loads and even a process crash.
   • In the catalog: SQL CPU, waits, and I/O on ReportServer and ReportServerTempDB.
   • In ExecutionLog3: TimeDataRetrieval and TimeProcessing, RequestType (Interactive versus Refresh Cache), and InstanceName, which tells you which node handled each request.

If the node CPU and refresh logs spike while SQL stays quiet, scale-out with a refresh-only node is the right first move. If the catalog is the busy one, add or size the SQL host first; adding PBIRS nodes will not fix a saturated database.

Microsoft's capacity-planning paper is a reference point only (it used a 5% concurrency assumption and specific sample reports), but it is consistent with putting cores on the report server first when CPU is the limiter.

https://learn.microsoft.com/en-us/sql/reporting-services/install-windows/configure-a-native-mode-report-server-scale-out-deployment

https://learn.microsoft.com/en-us/power-bi/report-server/scheduled-refresh-troubleshoot

https://learn.microsoft.com/en-us/power-bi/report-server/get-started

https://learn.microsoft.com/en-us/power-bi/report-server/capacity-planning

Hi, thanks for sharing this. We are seeing some similar performance issues and are currently trying to understand if they could be related to the PBIRS version.

Did you notice any change in report execution times after upgrading to May 2026?

We upgraded directly from May 2025 to September 2026, and since then we have seen significantly longer execution times for RDL reports used by data-driven subscriptions. Some subscriptions are now failing, and during these executions we sometimes see the Report Server reach 100% CPU.

We are comparing ExecutionLog3 before and after the upgrade to understand what changed. It would be interesting to know if you saw anything similar when moving to May 2026.