SQL Server is one of the most expensive products on a SPLA report, and it offers two licensing routes — per core and per Subscriber Access License — that can differ in cost by a wide margin for the same workload. Choosing the wrong route, or counting cores incorrectly on virtualised and shared hardware, is among the most common and costly SPLA mistakes. This guide sits under our Microsoft SPLA licensing guide and explains how to license SQL Server correctly under SPLA.
Unlike Windows Server, where per-core is effectively the only path, SQL Server genuinely gives the provider a choice of metric for many editions. That choice is the lever: a workload accessed by a small, defined population can be far cheaper on SAL, while a workload exposed to a large or unknowable population is almost always cheaper per core. Picking deliberately, rather than by habit, is where the savings live.
Per-core vs SAL for SQL Server
| Dimension | Per-core | SAL (per user/device) |
|---|---|---|
| Counts | Physical cores running SQL Server | Unique users/devices accessing SQL Server |
| Best fit | Large or unknowable user populations, internet-facing | Small, defined, internal user populations |
| Edition note | Enterprise for high-density virtualisation | Standard for limited-access workloads |
| Risk | Counting all cores on shared hosts | Under-counting access; provisioned-but-idle users |
The decision rule is the size and knowability of the user population. If you cannot enumerate and cap the users — typical of a public-facing SaaS application — per-core is the safe and usually cheaper choice, because SAL would require licensing every possible accessor. If the workload serves a small, named, internal group, SAL can be dramatically cheaper. The trap on SAL is the provisioned-but-idle user: access that was granted and never revoked still counts.
Per-core counting on virtualised hosts
SQL Server per-core counting follows the same hardware-first logic as Windows Server: you count physical cores, subject to per-processor and per-server minimums. On a virtualised host, the high-density route is SQL Server Enterprise licensed across all the host's physical cores, which then permits SQL Server to run in many virtual machines on that host. The low-density route is licensing only the virtual cores allocated to specific SQL virtual machines. As with Windows Server, density determines which wins — the mechanics mirror those in Windows Server SPLA licensing, and the two products are counted independently even when they share a host.
The shared-host over-count: on a shared cluster, SQL Server licensed per core must account for every physical core on which the SQL workload can run — including hosts it can fail over or live-migrate to. Providers who license only the "home" host under-report; providers who license the whole cluster when SQL is pinned to one host over-report. Pinning SQL workloads to defined hosts, and documenting the pinning, keeps the core count honest in both directions.
Shared, dedicated, and BYOL
Because SQL Server is costly, it is the product where a customer's existing Software Assurance is most worth using. A large customer who owns SQL Server licenses with Software Assurance can often bring them to a dedicated host under License Mobility, removing the line from the provider's SPLA report entirely. Whether that is available turns on the host being dedicated to the customer — see shared vs dedicated hardware — and on the broader SPLA-versus-BYOL trade-off in SPLA vs BYOL licensing.
Reporting SQL Server each month
The monthly report should state, per workload, whether SQL Server is licensed per core or by SAL, the edition, and the counted quantity, against the Product Terms in force for that month. The supporting evidence is a SQL Server deployment scan reconciled to the hosts and editions reported, plus, for SAL workloads, an access list that is actively maintained rather than allowed to accrete idle users. Reconciling this monthly catches the two failure modes — core over-count on shared hosts and SAL under-count from stale access — before they compound across years.
SQL Server findings are frequently the largest single component of a SPLA audit settlement, which is why disciplined SQL reporting repays the effort. Our advisors reconcile SQL deployment to reporting as part of Microsoft audit defense, and the full program context is in the SPLA licensing guide.
Common SQL Server reporting mistakes
The most consequential error is choosing the metric by habit rather than by analysis. A provider that defaults every SQL Server instance to per-core may be overpaying on small, internal workloads that would be far cheaper on SAL; a provider that defaults to SAL may be dangerously under-licensed on an internet-facing workload whose user population it cannot enumerate. The metric should be chosen per workload, with the test being whether the accessing population is small, known, and capped.
The second error is the failover over-count or under-count. SQL Server licensed per core must cover every physical host the instance can run on. Providers who license only the primary host under-report; providers who license an entire cluster when SQL is pinned to one host over-report. Both are corrected by pinning SQL workloads to defined hosts and licensing exactly those hosts.
The third error is the stale SAL list. On SAL-licensed SQL workloads, access granted and never revoked keeps counting. Worse, it counts even when no one uses it, so the cost is real while the value is zero. A monthly access review keeps the SAL count tied to genuine need.
When to revisit the SQL Server model
SQL Server licensing is not set-and-forget. A workload that was small and internal at launch can grow into a large, externally-accessed service, flipping the economics from SAL to per-core. A customer who acquires Software Assurance becomes a BYOL candidate for their SQL estate. A consolidation that moves SQL onto a denser cluster changes the per-core maths. The trigger points are predictable — major usage growth, a customer's licensing change, and any platform consolidation — and a review at each of them keeps SQL Server, usually the most expensive line on the report, correctly and economically licensed.