SQL Server Licensing 2025 – Core vs. CAL Models

SQL Server Licensing 2025 – Core vs. CAL Models

Introduction
SQL Server licensing has become a major risk and cost driver for enterprises in 2025. Microsoft’s complex licensing rules, especially the choice between per-core vs. Server+CAL models, can significantly impact IT budgets and compliance.

For CIOs, CFOs, and IT asset managers, this decision is a pivotal juncture in planning SQL Server deployments. The wrong licensing model can double your SQL Server costs or expose your organization to compliance audits.

In an era of tightening IT spend and aggressive vendor audits, aligning your SQL Server licensing model to your actual workload patterns is absolutely critical for reducing costs and avoiding compliance pitfalls.

Choosing the right model upfront can mean the difference between a cost-optimized SQL environment and an unexpected budget crisis. Read our guide to Microsoft Windows licensing.

Core Concepts – SQL Server Licensing Models in 2025

Microsoft offers two primary licensing models for SQL Server in 2025: Per-Core licensing and Server plus CAL (Client Access License) licensing.

Both models are available for SQL Server Standard Edition. Still, SQL Server Enterprise Edition is only sold under the per-core model (Server + CAL is not an option for Enterprise Edition).

The decision often boils down to workload characteristics and user counts:

• Per Core Licensing: Licenses the processing power itself. You purchase licenses for each CPU core on the server (sold in 2-core packs, with certain core minimums per server). This model allows unlimited user access to that server without requiring separate CALs for each user or device. It’s typically used for high-load servers, internet-facing applications, or scenarios where the number of users is large or unpredictable.
• Server + CAL Licensing: Licenses the server and each user (or device) that accesses it. You buy a SQL Server license for each server instance and separate CALs for each user or device that connects. This model is only available for the Standard edition and is cost-effective only when the user count is limited, well-known, and entirely internal (employees or on-premises devices). External or anonymous users are not covered by CALs, making this model unsuitable for public-facing systems.

Read how to optimize, Cost Optimization Strategies for Microsoft Server Licensing

SQL Server Standard vs. Enterprise 2025:

In practical terms, the Standard edition offers a lower-cost, basic feature set and the flexibility of either licensing approach (Core or CAL). Enterprise edition provides advanced performance and features (suitable for mission-critical applications) but mandates per-core licensing.

Enterprises often reserve the Enterprise edition for critical workloads and use the Standard edition for departmental or smaller applications to save cost. Choosing Standard with CALs might seem cheapest for a small user base. Still, if that user base grows or if workloads expand (e.g., virtualization or external access requirements), the economics shift quickly.

Example: A mid-size university initially licensed SQL Server Standard under the Server+CAL model for 200 faculty/staff users. This worked well until the university’s services grew to cover 800 users (including students and contractors).

Buying hundreds of additional CALs suddenly made this setup more expensive than if they had used per-core licensing from the start.

The takeaway: an organization must project its user growth and access patterns – the model that is cheapest today might become a costly trap as you scale.

Per Core Licensing Explained

Under SQL Server per-core licensing, you license the database server based on its CPU cores, not the number of users.

This model shines in several situations:

• High User Counts or Unpredictable Usage: Ideal for high-density workloads, web applications, or any scenario where the user count is large, fluctuating, or includes external users. You don’t need to track or limit the number of users connecting – whether it’s 100 employees or 100 million web visitors, the cost remains the same once the cores are licensed.
• License All Cores (Core Minimums): You must purchase licenses for all physical cores in the server (or all virtual cores allocated to the SQL Server VM, in virtual environments). Microsoft sells core licenses in packs of two. Notably, certain minimums apply – typically at least four core licenses per processor, and a minimum of 16 core licenses per server (even if your server has fewer cores). These core minimums ensure even small servers incur a baseline licensing cost.
• No CALs Required: Per-core licensing includes unlimited user access rights. This means no CALs are needed at all. You pay for the processing power, and in return, any number of users or devices (internal or external) can legally access the SQL Server.

Per-core licensing is often the only viable choice for customer-facing systems.

For example, a retail bank built a new online banking platform using SQL Server Enterprise. Because millions of external customers would be using the system, the bank wisely chose a per-core model. They licensed the SQL Servers running the platform based on the core count of the servers.

This approach provided them with a predictable, fixed cost for SQL licensing and avoided the chaos of managing CALs for an ever-growing customer base. In addition, since they used the Enterprise edition, they benefited from its performance features and could scale the number of database instances freely on that hardware.

The bank’s CIO noted that while the up-front license cost was high, it was still far cheaper (and simpler) than attempting a CAL model (which in this case would have been impossible, since CALs can’t practically be issued to external online users).

Per core licensing in this scenario eliminated user-tracking headaches and ensured compliance for an internet-facing application.

Server + CAL Licensing Explained.

The Server + CAL model is the more traditional way of licensing SQL Server, and in 2025, it remains available only for SQL Server Standard Edition.

In this model, you license each server and then obtain Client Access Licenses for every individual user or device that accesses SQL Server.

Key points for Server+CAL licensing:

• Server License + User/Device CALs: You need one SQL Server server license for each server (or each VM/instance of SQL Server Standard). Additionally, every distinct user or device that connects to any of these SQL Servers must have a CAL. You can choose User CALs (covering a named person for any devices they use) or Device CALs (covering a specific machine used by multiple people). Each CAL typically costs a few hundred dollars, and a server license is roughly around $1,000 (list price).
• Cost-Efficient for Small, Internal User Bases: This model can be very cost-effective if you have a limited number of users (and those users are all internal to your organization). For example, a small internal application accessed by 30 employees could be far cheaper on Server+CAL than licensing an entire multi-core server. SQL Server CAL licensing shines when the user count is low and stable: you pay a modest one-time fee per user rather than licensing a whole server’s cores, which might be underutilized.
• Not Suitable for Large or External Audiences: The CAL model breaks down if user counts grow or if you have external users. Notably, Microsoft’s licensing terms do not allow you to use CALs for most external (non-employee) users. In theory, Microsoft had an SQL Server External Connector license intended to cover unlimited external users per server, rather than individual CALs; however, this option is often overlooked and, in recent years, has effectively been phased out for SQL. In practice, if non-employees (such as customers, partners, or contractors) need access to a SQL-based application, an External Connector license (if available) can be expensive. It may not even be offered for newer SQL versions. The safer approach in such cases is to switch to per-core licensing. Many organizations fall short on this, continuing to operate a CAL model while allowing third parties to access the system, which puts them out of compliance.

Consider a manufacturing company that chose SQL Server Standard with CAL licensing for a small internal ERP database.

They purchased 50 user CALs for their employees and believed they were adequately covered. However, during a license audit, it was discovered that approximately 20 external contractors and partners were also occasionally accessing the database through a web portal.

None of those external users had CALs (and you cannot legally use internal CALs for external people). The result: Microsoft identified a licensing gap.

The manufacturer was faced with a hefty compliance penalty – a “true-up” bill of roughly $500,000 to cover unlicensed external use, including retroactive CAL costs and fines.

The lesson was harsh: if you opt for Server+CAL licensing, you must tightly control who has access to the system. Any external user access requires either purchasing the appropriate licensing (e.g., an External Connector for SQL Server, where applicable) or using the per-core model to avoid this issue altogether.

Virtualization Rights and License Mobility

Modern enterprises heavily use virtualization and cloud platforms, which adds another layer of complexity to SQL Server licensing.

How you license SQL Server in virtualized environments can drastically change your costs and compliance status:

• Virtualization Rights (Per Core Licensing): If you license SQL Server on a per-core basis, you have some advantageous options for virtualization, especially with Enterprise Edition. By licensing all the physical cores of a host server with Enterprise Edition and adding Software Assurance, you gain the right to run unlimited SQL Server VMs on that host. This is incredibly valuable for data center consolidation – essentially, a single Enterprise + SA license covering the whole host can replace dozens of separate VM licenses. Without Software Assurance, Enterprise core licenses typically allow a limited number of VMs equal to the number of core licenses (or you must individually license each VM’s cores). Standard Edition’s virtualization rights are much more limited: generally, Standard allows at most two SQL Server instances per licensed server (physical or virtual). If you need to run many SQL Server VMs, Standard’s model of licensing each VM (or each pair of VMs) becomes cumbersome and often more expensive than simply opting for Enterprise per core. In short, highly virtualized or cloud-heavy environments tend to favor the per-core model (and often Enterprise Edition) for simplicity and potentially huge cost savings.
• Server+CAL in Virtual Environments: If you use the Standard edition with Server+CAL in a virtualized setup, it can get tricky. Each SQL Server VM still needs its own server license, and all users of those VMs need CALs. If VMs are spun up and down dynamically, keeping track of license assignment can be a nightmare. Moreover, if your virtualization cluster moves VMs between physical hosts, you must ensure the licensing moves accordingly (or is sufficient on each host), which Server+CAL doesn’t natively account for. This is one reason large organizations rarely use the CAL model in enterprise virtualization scenarios – it’s operationally complex and risky.
• License Mobility (with Software Assurance): Microsoft imposes a rule that a SQL Server license without Software Assurance (SA) is tied to a specific server and cannot be reassigned to another server more frequently than once every 90 days. In a virtualized or cloud environment, that’s a serious limitation. License Mobility is a benefit you get by having Software Assurance on your SQL Server licenses. It allows you to move licenses between servers or to cloud services much more freely (e.g., you can migrate a VM running SQL to a different physical host or even bring your own license to a cloud VM on Azure/AWS without waiting 90 days). For any organization using hybrid cloud or frequent VM migrations, SA’s license mobility is practically essential to stay compliant.

Example: A SaaS company learned about virtualization licensing the hard way.

They ran about 100 SQL Server Standard edition VMs across a cluster of hosts. To save money, they initially licensed just a few physical hosts and assumed they could freely move the VMs around.

However, they did not purchase Software Assurance, so their licenses were not transferable under Microsoft’s 90-day reassignment rule.

Over a year, their automated orchestration moved SQL VMs for load balancing and hardware maintenance, inadvertently violating Microsoft’s licensing terms each time a VM ran on an unlicensed host.

When Microsoft’s auditors reviewed their environment, the lack of license mobility and dynamic VM placements resulted in a compliance gap valued at approximately $1.2 million due to unlicensed SQL instances.

The SaaS firm had to scramble to purchase additional licenses and add SA to enable proper license mobility going forward. The clear lesson: in highly virtualized environments, Enterprise Edition with per-core licensing plus Software Assurance is often the only safe and cost-effective way to license SQL Server.

It provides the flexibility for unlimited virtualization and the mobility to shift workloads without financial surprises.

Scenarios – When CAL vs. Core is Cheaper

It’s not always obvious which model will save money until you map it to your scenario. Below are a few common scenarios comparing costs and risks of Server+CAL vs. per-core licensing:

Interpreting the scenarios:

The first scenario presents a small-scale internal application, where licensing SQL Standard by CALs is clearly the most cost-effective approach and poses minimal compliance risk as long as the 50 users remain the only ones using the system.

In contrast, the second scenario (a large employee base and an external-facing web application) demonstrates that the CAL model simply doesn’t work – you cannot assign CALs to unknown external users, so per-core is the only viable choice.

The cost might look high, but attempting a CAL model isn’t even legally allowed in that case. The third scenario highlights a massive virtualization use-case: hundreds of SQL Server instances.

Here, enterprise-per-core licensing with Software Assurance is the only sensible approach. Yes, it’s expensive, but trying to license 400 SQL VMs with Standard edition and CALs (or even Standard per-core per VM) would be exponentially more complex and costly – not to mention likely non-compliant if VMs move around.

The key insight is that CAL vs. core has a break-even point: for Standard Edition, many organizations find that once you exceed roughly 100-150 users on a given SQL Server, the per-core model becomes more cost-effective.

Every enterprise should perform this analysis using its own numbers, considering not only current usage but also future growth and external access needs.

Common SQL Server Licensing Pitfalls

Even with a solid plan, organizations often stumble over Microsoft’s fine print. Here are common SQL Server licensing pitfalls to watch out for in 2025:

• Underestimating user growth in CAL models: Companies often start with a small user count and choose Server+CAL licensing, only to have that user base explode (due to business growth or new applications onboarding more users). If you don’t budget and acquire CALs for the new users, you’ll be out of compliance. Even if you do purchase them, the cost can skyrocket unexpectedly. It’s easy to outgrow the CAL model – and if you cross a certain threshold, you end up paying far more than a per-core license would have cost. Always project user growth when choosing CAL licensing.
• Forgetting to license contractors and external users: A very frequent audit finding is that organizations license their employees with CALs, but completely miss “non-employees” accessing the system. This includes temporary contractors, partners, clients, or external systems/users that indirectly query your database. Under CAL licensing, every human or device that accesses the database needs a license. If they aren’t your employees, you either need to have purchased CALs for them or covered the server with an External Connector license (where applicable). Many organizations mistakenly assume only employees need CALs – resulting in major compliance gaps. It’s safer to assume that any login to SQL Server requires a license unless proven otherwise.
• Misusing Standard edition in highly virtualized setups: Standard edition is attractive for its lower cost, but it’s not designed for large-scale virtualization or high-density VM scenarios. We often see companies spinning up dozens of SQL Server Standard VMs for different apps, each properly licensed in isolation, but forgetting that if those VMs are consolidated on a few physical hosts, it might have been cheaper (and simpler) to just license the hosts with Enterprise. Additionally, using Standard with the Server+CAL model across many VMs can be a licensing maze – tracking which users access which instance can turn into a compliance nightmare. If you have a heavy virtualization plan (for example, a private cloud with dynamic VM provisioning), strongly consider Enterprise per-core licensing to avoid this pitfall.
• Not leveraging Software Assurance for license mobility: If you’re moving toward cloud or already in a hybrid cloud environment, failing to include Software Assurance on your SQL licenses can be a costly mistake. Without SA, your licenses are essentially stuck to their original server allocations (remember the 90-day transfer rule). In practice, that means you cannot freely move your workloads to Azure or AWS using your existing licenses, nor can you quickly reassign licenses during failovers or load balancing. Organizations that skip SA to save money upfront often end up either paying again for new licenses in the cloud (double-paying for the same software) or getting dinged in an audit for improper reassignment. License mobility via SA is a critical right if you want flexibility – not having it is a risk if your infrastructure is fluid.

These pitfalls highlight how easy it is to fall out of compliance or exceed the budget if you don’t continually align your licensing with the evolution of your environment. Microsoft’s licensing documents are lengthy, and real-world use can diverge from initial plans, so periodic internal reviews are important.

Five Best Practices for SQL Server Licensing 2025

To mitigate risks and optimize costs, enterprise leaders should follow these best practices when managing SQL Server licenses in 2025:

1. Conduct Annual SQL License Audits: Don’t wait for Microsoft to audit you – audit yourself. At least once a year, inventory all SQL Server deployments (including production, test, DR, and virtual machines) and verify you have the appropriate licenses and CALs for each. Check the number of users/devices accessing each server and ensure it aligns with your CAL counts (if using CAL model). Proactively identifying and correcting any shortfalls is far less expensive and less painful than receiving a surprise compliance fine. An internal audit also strengthens your audit defense by having documentation ready if Microsoft comes knocking.
2. Choose Server+CAL Only for Stable, Limited User Scenarios: The Server+CAL model is best suited when you are confident that the user count will remain relatively low and predictable. For example, a departmental application for 20 accountants is a suitable candidate for CAL. However, always plan for the future – if there’s a chance that the application could roll out company-wide or open up to hundreds of users, think twice. It might be wiser to start with per-core licensing, or at least budget for a downgrade in the future. In short, use CALs in niche, controlled cases; otherwise, default to per-core if uncertainty exists.
3. Leverage Enterprise Edition for Virtualization and Consolidation: If your organization relies on virtualization or plans to consolidate multiple databases onto a few powerful servers, SQL Server Enterprise per core is your ideal choice. It may hurt your budget upfront, but it provides far greater flexibility. With Enterprise (especially with SA), you can run multiple instances on the same hardware without worrying about counting licenses for each VM. This not only reduces SQL Server licensing costs at scale, but also simplifies operations. The Standard edition is fine for smaller-scale applications, but once you’re dealing with dozens of SQL instances or complex cloud deployments, paying for Enterprise cores often pays back in terms of ease of management and risk avoidance.
4. Account for External Access Properly: Establish a policy to document all scenarios where non-employees (such as customers, partners, or third parties) may access your SQL Server data. For each such system, ensure you have a licensing strategy: either they are covered via an External Connector license on that server (if one is available and makes financial sense) or, more commonly, that server should be under a per-core licensing model. Never assume that just because an external user logs in through a front-end app, you don’t need to license them. If SQL Server backs the front-end, the licensing rules still apply. Clarifying this in design and architecture reviews can save you from compliance surprises later.
5. Negotiate True-Ups and License Renewals with Usage in Mind: In enterprise agreements, a “true-up” refers to the periodic reconciliation where you inform Microsoft of any increased usage (i.e., more servers, more cores, or more CAL users) and pay for it accordingly. Be strategic here. Avoid over-buying CALs “just in case” – purchase licenses based on actual usage and short-term forecast, then true-up if additional users actually come on board. Similarly, if you are phasing out a system or moving to the cloud, factor that into renewal discussions so you’re not caught paying for licenses you won’t need. Microsoft’s sales teams may push for larger license bundles or upgrades; stay grounded in your actual needs and consider alternatives (such as shifting to per-core or vice versa) at each renewal point. A well-planned true-up can sometimes be an opportunity to switch models if your environment has changed significantly (for example, moving from CAL to per-core as the user count surpasses the break-even point, or vice versa if workloads shrink).

By following these best practices, organizations can significantly reduce the risk of non-compliance and avoid overspending. It all boils down to staying informed, forward-thinking, and not taking Microsoft’s licensing terms for granted.

FAQs

When should I use SQL Server per core vs. CAL licensing?
Use the per-core licensing model when you have a large number of users (or an uncertain number of users), especially if those include external or public users. Core licensing is also recommended for heavily virtualized environments and whenever you need simplicity of unlimited connections. On the other hand, use the Server + CAL model for scenarios with a small, well-defined internal user base – for example, an application that only your accounting team (15 people) will ever access could be much cheaper on CALs. As a rough rule: if you expect more than about a hundred users on a SQL Server, or if users aren’t all employees, per-core is usually the way to go.

How many CALs do I need for contractors or third-party users?
Each contractor, vendor, or third-party user who directly or indirectly accesses your SQL Server requires a CAL, just as an employee would, if you are using the CAL model. If you have 10 contractors who log into an internal SQL-based system, that’s 10 extra User CALs you must have. In many cases, organizations find it cumbersome to license every outside user – this is one reason to consider per-core licensing or an External Connector license for external audiences. Remember, CALs are not transferable between users; each person needs their own. Always include contractors and partners in your license headcount if you stick with the CAL approach.

Does SQL Server Enterprise edition allow CAL licensing?
No. As of 2025, SQL Server Enterprise edition is only sold under the per-core licensing model. You cannot license Enterprise with Server and CAL. The CAL option is exclusive to SQL Server Standard edition (and prior versions, such as Business Intelligence edition in older releases, which is no longer offered). If you require Enterprise edition features (for instance, for higher performance, unlimited virtualization rights, advanced analytics, etc.), you must budget for per-core licenses.

What’s the minimum core count I must license per SQL Server?
Microsoft requires a minimum of 4 cores per processor to be licensed under the per-core model for any SQL Server. Additionally, there is a minimum of 16 core licenses per server. This effectively means even if a server has a single quad-core CPU (4 cores total), you still need to purchase 16 cores’ worth of licenses to meet the minimum. Core licenses are sold in two-packs, so a minimum server purchase is eight 2-core packs (8 x 2 = 16 cores). These rules ensure a baseline revenue for Microsoft, so even small deployments might have excess core capacity licensed. Always count your physical and/or virtual cores and apply these minimums when budgeting.

How does license mobility apply in cloud or hybrid environments?
License mobility, a benefit of Software Assurance, enables you to move your SQL Server licenses between on-premises servers and cloud environments more freely. In a cloud context (such as running SQL Server on Azure VM or Amazon EC2), license mobility means you can bring your own license (BYOL) instead of paying the cloud provider’s SQL licensing as part of the VM cost, and you can reassign that license as needed. For example, you could shift a license from one AWS VM to another, or from on-prem to Azure, without waiting 90 days, as long as both environments are covered under your SA. In hybrid setups, this means you can treat your licenses as a floating pool that can be used wherever capacity is required. Without license mobility, moving a workload to the cloud often means you’d have to pay for SQL Server again in the cloud, effectively double-paying or violating terms. Bottom line: If you plan any cloud integration or dynamic scaling, ensure you have SA on your SQL cores so you can fully utilize license mobility rights.

Can SQL Server CALs cover external users or access to a public website?
No, standard SQL Server CALs are intended for internal use (typically by employees or on-site devices). They do not extend to anonymous public users or external customer scenarios. If you have a public-facing website or application backed by SQL Server and you chose the Server+CAL model for some reason, technically, every single user of the website would require a CAL, which is not feasible. Historically, Microsoft offered an “External Connector” license as a way to cover unlimited external users for a server, but for SQL Server, this option has been deprecated or priced so high that it’s rarely practical. The realistic approach for any external or customer-facing system is to use per-core licensing on the SQL Server. That way, unlimited external users are automatically permitted. If you mistakenly use CAL licensing in an external scenario, you are likely out of compliance and at high risk of audit failure. Always evaluate your user audience: if it includes non-employees or an unknown number of users, the CAL model is not appropriate – switch to a per-core model.