The decision rule has two gates: Server+CAL exists only for Standard edition, and it only pays off when every human and device that touches the data — directly or through any layer of middleware — is countable, stable and small in number. Fail either gate, or run anything internet-facing or Enterprise edition, and per-core is not a choice but the default; pass both, and CAL licensing is cheaper right up until the population quietly grows past the crossover.
Published 13 February 2026 · Last reviewed 2 June 2026
Start with eligibility, because it settles many cases before any arithmetic. Enterprise edition is per-core only. The Server+CAL model is offered solely on Standard edition, so the metering question only exists for workloads that Standard's feature and capacity ceilings can carry. SQL Server 2025 — generally available since November 2025 — left this structure untouched: no new model, no changed minimums, though it did retire Web edition and continued Microsoft's push of a third path, pay-as-you-go through Azure Arc, which bills consumption hourly against an Azure subscription instead of perpetual licenses.
One more gate: workloads whose users cannot be enumerated — public websites, customer portals, anything internet-facing — are structurally per-core, because a CAL must be assigned to a named user or device and an anonymous public cannot hold CALs. What remains for the Server+CAL math is the classic internal line-of-business system: known headcount, known devices, modest core footprint.
This guide is general information about Microsoft commercial terms, not legal or licensing advice for your situation; the Product Terms and your agreement govern. It names no firms; the firm directory lists Microsoft-capable advisors with balanced pros and cons, listed, not ranked.
Per-core licenses the machine. On physical servers you license all physical cores, with a floor of four core licenses per processor, bought in two-core packs; hyper-threads are not double-counted. In virtual machines you license each virtual core with a floor of four per VM — which makes small two-vCore VMs disproportionately expensive and rewards consolidation. Enterprise edition with Software Assurance on every physical core of a host unlocks unlimited virtualization on that host, the mechanic that anchors most large virtualized estates. Once the cores are licensed, user count is irrelevant: ten users or ten million, the bill is the same.
Server+CAL licenses the population. Each operating system environment running SQL Server takes a server license, and then every user or device that accesses the data needs a Client Access License — user CALs for people on many devices, device CALs for shared workstations like shift floors and clinics. Two rules give the model its teeth. First, multiplexing: hardware or software that pools connections — an app server, a web tier, a reporting layer, an ESB — does not reduce the CAL count. The five hundred people behind one service account are five hundred CALs. Second, version: a CAL must be the same version as, or newer than, the server it accesses, so a server upgrade silently obsoletes older CAL stock.
| DIMENSION | PER-CORE | SERVER + CAL |
|---|---|---|
| Editions | Standard and Enterprise (Enterprise: per-core only) | Standard only |
| What is counted | Physical cores (min 4 per processor) or vCores (min 4 per VM), in 2-core packs | One server license per OSE + one CAL per user or device, however indirect the access |
| User population | Irrelevant — unlimited users and devices once cores are covered | The entire cost driver; must be enumerable and trackable |
| Internet-facing workloads | Supported — the only viable model | Not viable; anonymous users cannot hold CALs |
| Scaling behaviour | Cost tracks hardware: grows with cores, flat as users grow | Cost tracks headcount and integrations: flat as hardware grows, climbs with every new user, device or connected system |
| Virtualization | Per-VM vCore licensing; Enterprise + SA on all host cores = unlimited VMs on that host | Server license per OSE; CAL obligations unchanged by topology |
| SA / subscription leverage | Failover rights, license mobility, upgrade rights, hybrid benefit toward Azure | Same benefit family on the server license; CAL stock must keep version pace |
| Audit exposure profile | Core undercounts in virtual estates; unlicensed passive nodes; hybrid-benefit double-use | Multiplexing undercounts; stale CAL versions; device/user CAL mix drift |
| Third path (2026) | Pay-as-you-go via Azure Arc bills consumption hourly — no perpetual license, no CAL question, an Azure bill instead | |
Against a minimum-footprint Standard server, the published price relationship puts the crossover in the rough vicinity of 130 users or devices — below it the Server+CAL stack is cheaper, above it per-core wins, with the exact line moving as core counts rise and the user/device CAL mix shifts. Treat the figure as a direction, not a constant.
The operational problem is that the two sides of the comparison drift differently. A core count is a deliberate act — somebody provisions a server. A CAL population grows by itself: new hires, a second connected application, a BI tool rolled out to a department, an integration that quietly exposes the database to a system with its own thousand users. Server+CAL estates sized correctly at purchase are routinely far past the crossover — and out of compliance — years later without any single decision having been taken. An annual re-count against the multiplexing rule is the minimum discipline; modelling the flip before an agreement renewal is where the leverage is, because converting models mid-term is a negotiation, not an entitlement.
The same review should price the third path honestly: Arc-billed pay-as-you-go removes the CAL question entirely and suits spiky or short-lived workloads, but converts a capital asset into a perpetual operating bill — the familiar cloud trade, applied to a database license. A licensing advisory engagement typically runs all three models against real telemetry before a renewal locks the estate in.
Counting only direct logins. The multiplexing rule is the single most common SQL Server finding: the audit scopes every human and device behind the app tier, the estate counted only the service accounts. The gap is often an order of magnitude.
Public access on Server+CAL. A Standard server licensed with CALs acquires a web front-end years later. Anonymous users cannot hold CALs; the workload needed per-core from the day it faced the internet.
Four-core floors ignored in the VM sprawl. Dozens of two-vCore utility VMs each carry a four-core minimum. Per-core estates that licensed actual vCores rather than the floor undercount by design.
Passive nodes without Software Assurance. Failover rights for designated passive HA/DR instances ride on SA or subscription coverage. Clusters built for resilience while SA lapsed are licensed at half their real footprint.
CAL stock frozen at an old version. CALs must match or exceed the server version; a server upgrade without a CAL refresh turns the entire population non-compliant overnight.
Treating the model choice as permanent or as trivial. It is neither: conversions happen at renewal, on the vendor's terms, with the vendor's information advantage. Walking in with an independent count — and the right advisor to run it — is the difference between choosing a model and being assigned one. If the count has already become a dispute, that is compliance assessment territory.
The cloud-side commitment fork →
The vehicle the licenses ride on →
The suite-side displacement math →
How to pick the firm for this work →
Firms that model estates like this →
Every field guide on the site →
No. Server+CAL exists only for Standard edition. Enterprise edition is licensed per-core exclusively, and has been since the retirement of the old Server+CAL grandfathering. SQL Server 2025 did not change this: the model choice is real only for Standard, which is why the per-core-versus-CAL question is inseparable from the Standard-versus-Enterprise edition question.
On physical servers, all physical cores in the machine are licensed, with a minimum of four core licenses per processor, sold in two-core packs. In virtual machines, each virtual core is licensed with a minimum of four per VM. Hyper-threads are not double-counted on physical hosts. Enterprise edition with Software Assurance on all physical cores unlocks unlimited virtualization on that host; Standard edition has no such right.
No — this is the multiplexing rule, and it is the single most common SQL Server compliance finding. Every distinct user or device that accesses the server’s data, however indirectly — through an application server, a web front-end, a reporting layer, an integration bus — needs a CAL. A service account pooling five hundred users’ queries into one connection does not reduce the count to one; it leaves it at five hundred.
Against a minimum-footprint Standard deployment, the published price relationship puts the crossover at very roughly 130 users or devices — below it Server+CAL is cheaper, above it per-core wins, and the exact figure moves with core counts and CAL mix. The number is less important than its direction of travel: user populations grow, integrations multiply, and a Server+CAL estate sized comfortably today tends to drift across the line silently.
The model itself, nothing: per-core and Server+CAL carry forward unchanged, with the same minimums and Software Assurance mechanics. The notable packaging moves are the retirement of Web edition and the continued push of pay-as-you-go licensing through Azure Arc, which bills SQL Server consumption hourly as a third path alongside the two perpetual models. Editions and features moved more than money mechanics did.
Only with Software Assurance or an equivalent subscription right. SA-covered licenses permit designated passive failover instances — for high availability and disaster recovery within the benefit’s limits — without separate licenses. Passive nodes stood up without SA coverage are a classic audit finding: the cluster was built for resilience, but each node needed its own licenses the moment SA lapsed or never existed.
Running the count, modelling the crossover and negotiating the model conversion is exactly what a Microsoft licensing advisor is for. The directory lists the firms that do this work, with balanced pros and cons, listed, not ranked.
Tell us the vendor, the service you need and where things stand, and we will route your brief to firms that genuinely cover that combination. The directory and matching are free for buyers, no vendor ever sees your brief, and we add no markup.
Our weekly dispatch on vendor audit programs, regional developments and one buyer move. Subscribe to The Licensing Radar.