Estimate SQL Server licensing requirements and cost for on-prem deployments. Compare Per Physical Core, Per Virtual Core, and Server + CAL methods. See Perpetual + SA, Subscription, and PAYG pricing models with HA passive replica considerations and SA benefits explained.
Estimate SQL Server licensing requirements and cost across common on-prem deployment models. Settings update the URL bar live — copy the link to share the exact scenario.
Sizing and cost across pricing models. Updates live as you change settings.
✓ Version upgrades — Move to newer SQL Server versions during the SA term at no additional license cost.
✓ License Mobility — Move licenses between servers within the server farm without 90-day reassignment limits.
✓ Passive failover rights — One passive secondary per primary instance for HA/DR, provided it stays truly passive (no read queries, no backups, no DBCC).
The estimator does the maths — but the inputs determine whether the estimate is meaningful. These are the fields that most often cause expensive surprises.
Per Physical Core licenses every core on every host running SQL VMs, regardless of how many VMs use those cores. Per Virtual Core licenses only the vCPUs in SQL VMs.
Rule of thumb: Per Virtual Core wins when you have few SQL VMs on a fat host. Per Physical Core wins (especially with Enterprise + SA) when many SQL VMs share the same host — because Enterprise + SA grants unlimited SQL VMs on the licensed host. Switch between them in this tool to compare.
Microsoft requires a minimum of 4 cores per physical CPU and 4 cores per VM. A 2-vCPU SQL VM still costs the same as a 4-vCPU VM. This tool enforces the minimum automatically — but it means you can't "save money" by sizing SQL VMs at 1 or 2 vCPU. If you only need 2 vCPUs of compute, consolidating two such VMs into one 4-vCPU VM is cheaper.
The perpetual license is paid once. Software Assurance is paid every year for as long as you want SA benefits. A 5-year TCO of perpetual + SA can easily be 2× the perpetual price alone. Compare it carefully to subscription — sometimes subscription is cheaper across 5 years; sometimes perpetual is. The 3-year and 5-year TCO rows here exist exactly for that reason.
PAYG is priced per core per month, not per pack. Multiplied by 12 months and the cores you actually license, it usually overtakes Subscription within the first year. PAYG is meant for short-lived workloads (test environments, temporary spikes) — not for steady-state production.
The most common SQL licensing mistake. Microsoft's "free passive secondary with SA" benefit requires the secondary to do nothing useful: no read-only queries, no backups, no DBCC, no monitoring queries. The moment you offload reads to the secondary, it stops being passive and needs its own license set. Microsoft tightened this rule in 2022. Tick the HA checkbox in this tool only if your secondary is truly idle.
The pre-filled prices are public reference values used to demonstrate the calculation. Real prices depend on your contract — Enterprise Agreement, CSP, Open Value, distributor markup, region, currency. Replace every pricing field with your actual quoted price before relying on the totals.
Standard and Enterprise have different licensing rules and very different feature sets. Always Encrypted with secure enclaves, online operations, partitioning, transparent data encryption (without SA), and many high-availability features are Enterprise-only. Don't pick Standard purely on price if your workload needs Enterprise features — you'll end up double-paying when you migrate.
Server + CAL is Standard-only since SQL Server 2012. It's cheapest only when you have a small, well-known user count (e.g. fewer than ~25 users for a single instance) and you're certain that count won't grow. Adding users later means buying more CALs; growing your DB workload means buying core licenses anyway. Most modern deployments skip Server + CAL.
Quick comparison of the three on-prem methods.