Software Licensing by Core: How to Choose a CPU

When choosing a server processor, it is easy to focus on frequency, core count, cache, and thermal design power. But in enterprise infrastructure, that is often only half the picture. The other half is licensing. For Windows Server, SQL Server, some VMware/Broadcom products, and a range of Oracle solutions, the licensing model can affect the overall economics more strongly than the price difference between two CPUs. With Microsoft Windows Server, when licensing by physical cores, you must license all physical cores, with a minimum of 8 cores per processor and 16 cores per server. With Oracle Processor metric licensing, the number of licenses depends not only on the number of cores, but also on the coefficient in the Core Factor Table. Current Broadcom/VMware per-core models also use a minimum licensing volume per processor.

This leads to a simple conclusion: the “most powerful” processor is not always the most cost-effective one. If two servers cost about the same, but one has 16 fast cores and the other has 32 slower ones, the second may turn out to be significantly more expensive in licensing while delivering comparable application performance. That is why CPUs for licensed software are chosen not by core count alone, but by how much useful performance each licensed core delivers.

Why You Cannot Choose a CPU Separately from the Licensing Model

For open source services or some SaaS workloads, the number of cores may not be critical from a licensing perspective. But in the enterprise segment, what is licensed is not the “server as a whole,” but a specific entity: physical cores, sockets, vCPUs, or a processor equivalent according to the vendor’s rules.

It is important not to confuse the terms here:

• physical core — a physical CPU core;
• thread — an SMT/Hyper-Threading logical thread;
• socket — a physical processor socket;
• vCPU — a virtual processor in a hypervisor or cloud;
• licensed core — a core that falls under the licensing rules;
• processor metric — a licensable unit calculated using the vendor’s formula.

These are not the same thing. There are usually more threads than physical cores, but licensing is more often tied specifically to physical cores. Another trap is minimum thresholds. If a vendor has a rule such as “at least N cores per processor,” then a low-core configuration does not always deliver the savings you would expect.

Before choosing a CPU, you need to answer six questions:

• How exactly is the required product licensed?
• Are physical cores, sockets, vCPUs, or a processor metric being counted?
• Is there a minimum per server or minimum per processor?
• Are there coefficients based on CPU architecture?
• Is the whole host licensed, or only dedicated VMs/cores?
• Are there additional requirements such as CALs, subscriptions, or Software Assurance?

Without these answers, processor selection turns into guesswork.

Which Licensing Models Are Most Common

In practice, it is useful to keep in mind not dozens of special cases, but four basic models.

Licensing by Physical Cores

This is one of the most important scenarios for server infrastructure. With Windows Server, all physical cores in the server are licensed, with a minimum of 8 cores per processor and 16 cores per server. With SQL Server, the corresponding editions and scenarios also use a core-based model. This means that every additional core can directly increase licensing cost.

Licensing per CPU or per CPU with Core Limits

Historically, this model was more widespread. In current practice, it is often transformed: the license may be tied to a CPU, but cover it only up to a certain number of cores, or use a minimum core entitlement per processor. For current Broadcom/VMware products under the per-core model, the minimum purchasable capacity is 16 cores per CPU. This immediately changes the math for low-core and high-core configurations.

Licensing by Processor Coefficient

This is typical for some Oracle products. In this type of scheme, the number of required licenses depends not only on the number of cores, but also on the coefficient for the specific processor type. The same 32-core CPU in different architectural families can result in a different number of licenses. That is why looking only at core count is risky here: you need to check the Core Factor Table and the rules for the specific product.

Licensing by vCPU and Cloud Instances

In the cloud and in virtualized environments, the rules may differ from bare metal. For example, Oracle explicitly states that in Authorized Cloud Environments, the Core Factor Table is not applied the same way as on physical hardware. This is an important point: you cannot automatically переносить on-prem rules to the cloud, or vice versa.

The Main Principle: Maximum Performance per Licensed Core

When licenses are counted by core, what matters is not just the server’s total throughput. A more important metric is useful performance per licensed core.

Why this matters:

• every additional core can cost money not only in hardware, but also in licenses;
• many enterprise applications do not scale linearly;
• for OLTP, ERP, CRM, and some middleware, latency and single-core performance matter more than the maximum number of parallel threads;
• high core density is not always useful: sometimes it simply inflates licensing cost.

This leads to a practical rule. With core-based licensing, a CPU with fewer but stronger cores is often more advantageous if the workload is sensitive to single-thread performance and does not scale perfectly.

This is especially true when:

• the license is counted by physical cores;
• the application scales poorly across cores;
• response time and individual thread performance matter;
• the server is being purchased for one specific licensed system;
• the number of instances is limited in advance.

More cores are justified under other conditions:

• the license does not depend on the number of cores;
• the workload parallelizes well;
• the server is intended to consolidate multiple services;
• a licensing model based on vCPU, subscription, or other rules is used;
• the task is limited by parallelism rather than single-core speed.

How to Compare CPUs in Licensed Scenarios

In practice, the best choice is made not from marketing specifications, but by following an algorithm.

Step 1. Determine the Licensable Entity

You need to understand exactly what is being counted: physical cores, sockets, vCPUs, a processor equivalent, or a minimum threshold per CPU/server. This step cannot be skipped. Reading the vendor’s licensing guide is mandatory, and in ambiguous scenarios it is better to also consult a specialist from the vendor. Advice online and from suppliers may be inaccurate, including because licensing models periodically change (for example, VMware was licensed by sockets not long ago).

Step 2. Fix the Workload Type

A transactional database is one thing, virtualization of mixed services is another, analytics is a third. The same CPU may be cost-effective in one scenario and not in another.

Step 3. Estimate the Required Performance for the Specific Task

Do not look at “more powerful in general,” but at:

• latency;
• throughput;
• peak load;
• growth requirements for the next 2–3 years;
• HA/DR scenarios.

Step 4. Calculate Licensing on Top of Hardware Cost

The correct formula looks like this:

Total cost of ownership = server cost + license cost + support/subscription + growth reserve

It is precisely at this stage that it often becomes clear that a CPU that appears cheaper makes the project more expensive, or that a small overpayment “for cores” changes the total cost of ownership dramatically.

Step 5. Compare Candidates Using the “Useful Performance / Licensed Core” Metric

This is the most practical metric for such tasks. Not “how many cores,” but “how much result do we get from each paid-for core.”

How the Licensing Model Affects CPU Selection

Where Overpayment Happens Most Often

Confusing Cores and Threads

SMT and Hyper-Threading increase compute density, but they do not necessarily make the server “twice as licensable.” Threads and physical cores are different entities.

Ignoring Minimum Licensing Rules

If Windows Server has a minimum of 8 cores per processor and 16 per server, then a 6-core or 10-core configuration will not necessarily deliver the savings expected from simple arithmetic. This is one of the most typical miscalculations.

Buying a CPU “With Headroom” That Is Not Needed

Additional cores are often bought “for the future,” but with core-based licensing this headroom is paid for immediately in both hardware and licenses. If the growth plan is not confirmed, such headroom may turn into an expensive mistake.

Applying On-Prem Rules to the Cloud Without Verification

Oracle has separate rules for cloud scenarios, and the Core Factor Table is not applied in Authorized Cloud Environments the same way as on a physical server.

Looking Only at Benchmarks

A synthetic benchmark helps you understand the CPU class, but it does not answer the main question: how much useful application performance you get per licensed core.

One Socket or Two

The choice between 1P and 2P does not come down to “two sockets are better.” With core-based licensing, it depends on the balance between licenses and architectural requirements.

One socket is often more advantageous if:

• the workload is moderate;
• one platform has enough memory and PCIe resources;
• there is no consolidation task;
• it is important to minimize the number of licensed cores and NUMA complexity.

Two sockets may be justified if:

• a large amount of memory is required;
• more PCIe lanes are needed;
• consolidation of multiple services is planned;
• there is real growth reserve that will actually be used.

But if the software is licensed by all physical cores in the server, a second socket without practical necessity can sharply worsen the economics of the project.

Practical Scenarios

SQL Server and Transactional Databases

For SQL Server, core-based licensing makes per-core performance especially important. In transactional systems, a smaller number of faster cores is often more advantageous than maximum core density. This helps deliver the required performance without unnecessary growth in licensing cost.

Windows Server for Infrastructure Roles

If the server performs roles such as AD, file server, DNS, DHCP, or similar tasks, a high-frequency CPU is not always necessary. It is important not to buy more cores than are actually needed, especially taking the 8/16 minimum into account. Here, an economically reasonable configuration is often better than a “top-end” processor.

Oracle Workloads

With Oracle, you cannot look only at core count. Processor metric and the Core Factor Table mean that CPU architecture affects the number of licenses. Sometimes the difference in licensing math matters more than the difference in server price, or even a moderate difference in performance.

Virtualization and the VMware Pool

For current Broadcom/VMware per-core models, high core density is not free. You need to calculate licensing for the entire ESXi host pool and keep the minimum of 16 cores per CPU in mind. Here, the processor is chosen not in isolation, but together with the overall licensing model of the virtualization stack.

CPU Selection Checklist for Licensed Software

Conclusion

With per-core licensing, the optimal CPU is not the one that simply has more cores, but the one that gives the target workload the maximum useful performance at the minimum cost of licensed compute resources.

The correct sequence is always the same: first determine the licensing model, then the workload profile, then calculate scaling limits, and only after that choose the processor. In many scenarios, the best metric is performance per licensed core plus total cost of ownership.

And one final point: even if the general logic is clear, before purchasing you must always check the current licensing terms for the specific product, edition, and sales channel. Details matter in this area, and vendors change them more often than it seems.