PBRS licensing (Server+CAL vs Per-Core) and implementation advice for an on-prem deployment

DemurTsertsva Hi!

1. Edition & the SA change - yes, you're correct

With SQL Server 2025, Power BI Report Server use rights are included with both Standard and Enterprise core licenses, and Software Assurance is no longer required. This is a real change: on 2022 and earlier, PBIRS rights only came with Enterprise + active SA (or via Power BI Premium / Fabric F64+), and the right expired when SA lapsed. Microsoft's official source is the Reporting Services Consolidation FAQ(opens in new window) - see the "What editions of SQL Server 2025 include PBIRS?" section.

One caveat worth stating loudly: the new rights apply only to SQL Server 2025 licenses. You can't bolt PBIRS onto older 2022/earlier Standard or out-of-SA Enterprise licenses - those still follow the old rules.

So yes, for a brand-new on-prem deployment, Standard 2025 is the budget-friendly route versus the Fabric F64+ path.

Practical Standard-vs-Enterprise limitations to factor in:

• Virtualization. Enterprise + SA gives unlimited virtualization (license all physical host cores > unlimited VMs + live migration/vMotion across the cluster). Standard does not - you license the cores assigned to each VM (4-core minimum per OSE), and you don't get the same mobility rights. If you plan to run PBIRS as a roaming VM across a Hyper-V/VMware cluster, that's an Enterprise-shaped requirement.
• Failover/HA-DR. Free passive failover replicas are an SA benefit. With SA-less Standard, a passive HA or DR instance generally needs to be licensed too. If high availability matters, price that in.
• Standard's usual engine ceilings (memory/core caps) also apply, though for a 40-person reporting server they're rarely the bottleneck.

2. Server + CAL vs Per-Core - read the PBIRS grant carefully

Here's the nuance that trips people up. The SQL Server 2025 Product Terms express the PBIRS right specifically in core terms: you may run PBIRS on "a maximum number of cores equal to the number of SQL Server Standard or Enterprise Edition Core Licenses assigned to the Licensed Server, subject to a minimum of four core licenses per OSE."

In other words, the documented PBIRS use right is tied to core licenses. Server + CAL is a valid model for the SQL Server database engine on Standard, but the PBIRS entitlement language is written around core licensing - so I'd treat Per-Core as the relevant model for a PBIRS box and confirm with your licensing specialist/LSP before assuming a Server+CAL purchase conveys PBIRS rights. Don't take a forum post (including mine!) as your contractual answer here.

On 4 cores for ~40 users: 4 is the licensing floor, not a sizing recommendation. Whether it's enough is a performance question, not a licensing one, and it depends on:

• How many .pbix (interactive) reports vs .rdl (paginated) - PBIX models load into memory, so RAM is usually your real constraint, not core count.
• Concurrency (how many of the 40 actually hit reports simultaneously - usually a fraction).
• Scheduled refresh load and model sizes.

For a 40-person department with light-to-moderate concurrency and modestly sized models, 4 cores + generous RAM is often a reasonable starting point, but I'd size RAM first and be ready to scale cores if you've got heavy interactive PBIX usage or chunky refresh windows. For most departments this size, Per-Core on Standard tends to land cheaper than chasing CALs, especially once you factor the PBIRS core-based grant above.

3. Implementation gotchas & hidden costs

• Power BI Pro to publish - yes, still required, and your understanding is right. Anyone who publishes .pbix (Power BI) reports to the server needs a Power BI Pro license (or PPU). Key clarifications:
  • It's per publisher/author, not per viewer. Viewers/consumers need nothing - no per-user license to read or interact with reports on PBIRS.
  • It applies to Power BI (.pbix) report publishing. Pure paginated/RDL authoring does not require Pro.
  • You don't necessarily need 40 Pro licenses - only your actual report authors. Many shops run a handful of Pro licenses (or even a single publishing account) for the people who push content. Size it to your author count, not your user count.
• Quarterly updates. PBIRS follows the Modern Lifecycle Policy - you must apply quarterly releases to stay supported, which is a bigger cadence than the optional SQL Server CU model. Bake patch/testing cycles into your ops plan.
• Despite the name, PBIRS is fully air-gapped-friendly - it does not phone home to the Power BI service, so it suits your confidential/no-cloud requirement well. Same isolation you'd have had with SSRS.
• Other budget items people forget: a separate SQL Server database to host the ReportServer catalog (it doesn't have to be on the same box, but those cores need licensing too if separate), Power BI Desktop "optimized for Report Server" (free, but it's a distinct release cadence from regular Desktop — match versions to your server), gateway/data-source connectivity, and SSL certs for the portal.

Bottom line: for a 40-person, no-cloud deployment, SQL Server 2025 Standard (Per-Core) + a small number of Power BI Pro licenses for your authors is very likely your most cost-effective path - just validate the Server+CAL-vs-Core point and any HA/virtualization needs with your Microsoft licensing contact before you buy.

Hope that helps!

💡 Did I answer your question? Mark my post as a solution!

👍 Kudos are appreciated

🔥 Proud to be a Super User!

Hi DemurTsertsva ,
 

Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to the BeaBF  for sharing valuable insights.
 

Could you please confirm if your issue has been resolved using the suggested approach? This will help other community members facing similar scenarios.
 

Thank you for being part of the Microsoft Fabric Community.
 

Hi DemurTsertsva ,

Just checking in to see if the previous response helped resolve your issue. If not, feel free to share your questions and we’ll be glad to assist.

Thank you.