SQL Server 2025 CAL Review: When Server Plus CAL Beats Core Licensing

Fix it now

A CAL is not a copy of SQL Server. It is permission for one user or one device to reach a server licensed under the server plus CAL model, and it exists because counting people is sometimes far cheaper than counting cores. Choosing the wrong model is expensive and awkward to unwind, so do the arithmetic before you order.

1. Use server plus CAL when the user population is known, countable, internal and small relative to the core count of the host.
2. Use per core for internet-facing applications, external users, unknown user counts, or many users on a small server.
3. Pick device CALs for shift workers sharing terminals and user CALs for one person using a laptop, a desktop and a phone. Mixing the two types is permitted and usually cheapest.
4. Remember the model is Standard only. Enterprise is licensed per core, with no CAL option at all.
5. Count a hardware partition or blade as a separate server, because that is how Microsoft defines it, and that is what decides your server licence count.
6. If you could not produce a defensible user list during a review, licence per core and stop counting.

Failover rights are a Software Assurance benefit and they cover both halves of this model: the rights require Software Assurance for the licensed server and for the CALs.

If the ratio is obvious, buy on it. If it is close, the next section is about the two things that move the answer more than headcount does.

Why it happens

You buy one server licence for each operating system environment running an instance, then one CAL for every user or device that accesses it. The two parts are bought separately and neither works without the other: a server licence with no CALs covers nobody, and CALs with no server licence cover nothing. Microsoft defines a server here as the physical hardware system, and states that any hardware partition or blade counts as a separate server, which is the detail that catches people licensing blade chassis.

CALs are not tied to a particular server. Microsoft’s guidance is explicit that a user or device assigned a single CAL can access more than one licensed SQL Server, which is what makes the model attractive for organisations running several small instances. They are version-bound in the other direction: a user CAL allows access to the corresponding version of the server software or earlier versions, so upgrading servers without upgrading CALs leaves you short while the reverse is fine.

You may mix user and device CALs across the organisation. Nothing requires you to standardise, so count both ways for each group of staff and buy whichever produces the smaller number for that group. A warehouse on three shifts and a consulting team with three devices each should be licensed differently, and doing so is normal rather than clever.

Multiplexing is where this model goes wrong, and Microsoft’s wording leaves no room: using hardware or software that reduces the number of devices or users that directly access or use the software does not reduce the number of CALs required. The guidance adds two clarifications worth quoting to anyone who argues the point. CALs are required even when the server is accessed indirectly. And all devices accessing SQL Server require a CAL even if they are not attended by a human, which pulls in kiosks, scanners, tills and monitoring agents.

The same reasoning applies to reporting layers. If a nightly job copies data into a reporting database that people read, the people reading it are still accessing SQL Server data. This is the single most common finding when a licensing position is reviewed, and it is much cheaper to find yourself than to have somebody find it for you.

The crossover moved in this release, which is worth knowing if your last calculation is a couple of years old. SQL Server 2025 Standard’s maximum compute capacity is 32 licensed cores rather than the 24 of earlier versions. That raises the ceiling on how large a server plus CAL host can be, and it changes the point at which counting people stops being cheaper than counting cores. Redo the sum on your current hardware rather than repeating a conclusion reached against the old limit.

Full reference

Which model wins, and why

Counting correctly the first time

• Every human who reads or writes the data, including administrators, support staff and anyone using a reporting tool.
• Every device that accesses the server without a named user attached to it: a kiosk, a scanner, a shop-floor terminal, a monitoring agent.
• Users behind any application, portal or middleware that connects on their behalf, because indirect access still requires a CAL.
• Contractors and temporary staff for as long as they have access.
• External parties, which is usually the point at which you stop counting and licence per core instead.

Doing the sum properly

1. Count the operating system environments running instances. That is your server licence count, remembering that a partition or blade is a separate server.
2. Count users, and separately count devices, group by group rather than for the whole organisation.
3. Price server plus CAL with those numbers, mixing CAL types where it helps.
4. Price per core for the same hosts, remembering the minimum of four core licences per physical processor and four per virtual machine, sold in two-core packs.
5. Compare, then repeat the exercise the next time you replace a server with one that has twice the cores, because the answer flips at a ratio rather than at a headcount.

Software Assurance, failover and the rights people assume they have

The failover entitlement is the one most often misdescribed. Microsoft’s terms give you, for each primary workload, one failover operating system environment for any purpose and two more specifically for disaster recovery, and state that these failover rights require Software Assurance for both the licensed server and the CALs where CALs are used. A passive replica is not free by default; it is free because you are paying for Software Assurance, and dropping that to reduce a quote removes the entitlement with it.

The second commonly assumed right is version currency. A perpetual CAL keeps covering the version it was bought for indefinitely and does not reach forwards. Software Assurance on the CALs is what keeps them matched to servers as you upgrade, and it is the thing to price when you know a server refresh is coming inside the term.

Signals that you are on the wrong model

• Somebody is arguing about whether a service account counts as a user. That argument is the answer: licence per core.
• The user list is maintained by nobody in particular and was last accurate two reorganisations ago.
• Anyone outside the organisation touches the data, even through a portal.
• The host was replaced with one that has twice the cores and nobody redid the comparison.
• You are buying CALs for a server that also hosts an Enterprise edition instance, which has no CAL model at all.

Questions people ask about this