Priced Per Core

In September 2014 the top part in Intel's two-socket Xeon line had eighteen cores and listed at $4,115, and a machine built around a pair of them was a large server by the standards of the day. In June 2024 Intel was shipping 144 cores in a single socket. In October 2024 AMD shipped 192. The chip did not get ten times more expensive over that decade, which was rather the point of the exercise.

What did not move is the unit a great deal of enterprise software is billed in. The license is per core, and cores are what the hardware industry spent ten years learning to manufacture more of. So a consolidation that halves your server count, halves the power draw and halves the rack space can double the software bill on the same day, and the technically correct decision and the commercially cheap one now point in different directions on every refresh.

Here is the sentence the rest of this is about. Any metric a vendor bills on eventually becomes a constraint your engineers design around, whether or not anybody told them to. Per-core licensing did not simply get expensive, which would be a procurement problem. It reached into architecture, and it is now helping decide how large hosts are, where clusters are cut, and which nodes a workload is permitted to run on.

I am not going to relitigate any particular renewal. The shock that followed Broadcom closing its VMware acquisition in November 2023 and ending perpetual licensing a month later has been argued to death, on this site among others, and the price was never the interesting part. The counting rule underneath the price is a design input now, and almost nobody writes it down as one.

The count starts at a floor. Per-core pricing is rarely a straight count. Windows Server 2016, the release where Microsoft moved from per-processor to per-core, set a minimum of eight core licenses for each physical processor and sixteen for each server, sold in packs of two. A floor means a four-core host and a sixteen-core host cost the same, which pushes you toward fewer and denser machines. The meter above the floor then charges you for exactly that density. Both rules are reasonable and they point in opposite directions.

You cannot buy your way past an edition cap. A floor sets a price you cannot go below. A cap sets a chip you cannot use. Microsoft documents that one instance of SQL Server Standard is limited to the lesser of four sockets or 24 cores. Put Standard on a 96-core socket and three quarters of the processor is unreachable to it at any price short of the Enterprise edition, which is a hardware specification living inside a license agreement.

Multipliers are where the count stops being a count. Several vendors publish a factor table that converts physical cores into billable units by processor family, so the quantity you are charged for depends on which chip you bought rather than on how much work it does. As a rough performance normalization that is defensible. It is also the point at which a buyer can no longer check the arithmetic without the vendor's document open beside the invoice, and a metric you cannot verify is a metric you are accepting on trust.

The term is signed against hardware you have not bought. A multi-year agreement fixes the metric and leaves the quantity - your future core count - entirely outside the contract. Nobody signing a three-year term models it against the refresh landing in year two, because the refresh business case and the renewal live in different meetings and different budgets. The rate is agreed in one room, the multiplier is decided in another, and the two are reconciled for the first time when the true-up arrives.

License-driven placement is real and it is everywhere. A cluster is partitioned so the entitled product only ever runs on a subset of nodes. Affinity rules pin a workload to three hosts out of twelve. Hosts are specified deliberately smaller than the ones the vendor would happily sell, and capacity sits idle on purpose because switching it on would make it countable. Not one of those is an engineering conclusion, and all of them are written into engineering artifacts.

Each is also an availability decision. A workload restricted to three hosts has fewer failures to absorb before it is in trouble, and a cluster cut along entitlement lines is a cluster whose fault boundaries no longer match its physical ones. These are precisely the choices an architecture review exists to interrogate, and they arrive at the review already made, defended by a number nobody in the room is cleared to see.

They go unexamined because they are never recorded as what they are. The diagram says three hosts. The runbook says three hosts. Neither says that it is three because of a counting rule agreed in a renewal two years ago by somebody who has since left. So an engineer proposes moving it to six, cannot find a reason against, and is right on every ground available to them.

I would go further. This is the most common undocumented constraint I run into, more common than security requirements and much more common than performance ones, and the reason is that the other two leave artifacts. A firewall rule exists as an object. A benchmark exists as a result. A licensing constraint exists only as a shape in an architecture, and a shape looks exactly like a preference.

The question is cores it can reach, or cores it uses. In a virtualized estate a workload does not live on a host, it lives on a cluster, and live migration means it can start anywhere in that cluster. Some agreements bill for the cores it actually runs on. Others bill for every core it could reach. On a twelve node cluster those two readings differ by a factor of twelve, and which one applies is settled by a sentence in a contract rather than by anything technical.

You license the host, or you license the guest. Counting the virtual cores assigned to a guest sounds cheaper than counting the physical ones underneath, and often is, until somebody resizes the guest. Per-guest terms usually carry their own floor, so a large number of small machines can cost more than one big one, which exactly inverts the incentive the physical rule creates. Neither reading is wrong and both are countable. The only question is which one you agreed to.

A core is worth different amounts depending where it runs. The clearest demonstration is Azure Hybrid Benefit, where Microsoft publishes the exchange rate. One SQL Server Enterprise core owned on premises buys four vCores in the General Purpose tier and one vCore in Business Critical. One Standard core buys one General Purpose vCore, and it takes four of them to buy a single Business Critical one. Same core, four rates, decided entirely by which service you point it at.

The metric changes again when you rent it. Take the same software as a license-included cloud instance and the meter stops being cores you own and becomes vCPU-hours you consume, with the software cost folded into the compute rate where nothing audits it separately. That is genuinely simpler, and it is also how a software line item vanishes into an infrastructure one. Microsoft notes that license mobility under Software Assurance covers Azure infrastructure and EC2 alike, so owning against renting the license is a decision that outlives the choice of provider.

Every billing metric is a bet about what correlates with the value a customer receives, and every one of them bends a decision somewhere else. That is arithmetic rather than criticism. If a number appears on an invoice, somebody eventually optimizes it, and what gets distorted is whatever that number happened to be standing next to.

• Per user punishes adoption, which is the wrong thing to punish. A tool that becomes useful to a second team gets more expensive the week it does, so the sensible local move is to restrict access, and that is how an observability platform ends up with nine seats in a company of hundreds.
• Per employee decouples the bill from usage entirely. It is at least honest about being a tax rather than a meter, and it charges for people who will never open the product, which makes it impossible to reduce by using the software less and equally impossible to explain to anyone outside the room where it was signed.
• Per socket was the previous answer, and it is why we are here. It stopped tracking anything once one socket could hold nearly two hundred cores, and going back to it now would hand every buyer an order of magnitude for free, which is exactly why nobody is offering it.
• Consumption tracks delivered value better than any of these. It also relocates the distortion into engineering: teams stop instrumenting, stop retaining, stop running the batch job that would have answered the question, and the saving shows up as a smaller invoice and a slower organization that nobody connects to it.

Read down that list and the pattern is that no metric here is fair or unfair. Each is a lever. The buyer's job is not to find the honest metric, because there is not one, but to work out in advance which of their own decisions the chosen metric is going to start making for them.

Per-core is not arbitrary. It started as a decent proxy: more cores meant more throughput, more throughput meant more value delivered, and the customer getting more paid more. It is also auditable in a way almost nothing else is. A core count is a fact about a machine that both parties can establish without trusting each other, and that property is why it outlived several cleaner-sounding metrics that nobody could verify.

The alternatives are frequently worse for the buyer rather than better. Per-employee charges for people who never touch the product. Consumption hands the vendor the ability to reprice by redefining a unit. A negotiated flat fee sounds ideal and is available only to buyers large enough to negotiate, which means the small customer subsidizes the large one. Metering is not the grievance, and a vendor that stopped metering would not be cheaper.

The harder concession is that my argument does not apply evenly, and I should say where it fails outright. For software whose value genuinely scales with the compute beneath it - a database engine serving more transactions on a wider machine, an analytics engine finishing in a quarter of the time - per-core still tracks value about as well as it ever did. A customer moving that workload onto 192 cores really is getting proportionally more, and there I have no complaint at all. It is a large class of software.

What survives is narrower. A management agent, a backup client, a monitoring collector, a middleware runtime, an operating system: what these deliver is a function of how many machines and how much data they look after, not of how wide the chip underneath happens to be. Billing them per core means their price tracks somebody else's processor roadmap, which neither party to the contract chose and neither is better off for.

Model the renewal before approving the hardware. The refresh business case is written by infrastructure and the renewal is signed by procurement, and the two documents rarely appear in the same meeting. They should. Halving the host count while doubling the core count is a good hardware decision and possibly a bad total one, and the only way to find out is to price the same consolidation against every per-core agreement you hold before the order goes out.

Get the counting rule in writing, in your own words. Not the price, the rule. Which cores count, whether a workload is charged for what it can reach or what it runs on, what happens when a cluster grows by a node, and what a core is worth if the workload moves to a rented instance. Write your reading down and send it back for confirmation, because the expensive disagreements are never about the rate.

Label the constraints that are commercial. Every deliberately undersized host, every affinity rule and every cluster boundary that does not follow a failure domain should carry a line saying why. One sentence in the runbook is enough: this is a licensing constraint, agreed in this renewal, revisit it at the next one. Without it the constraint becomes folklore inside two years, and folklore is never reviewed when the contract that caused it changes.

Know what your cheaper edition can address. Edition caps are a hardware specification hiding in a license and they are checkable in an afternoon. If the standard edition of your database tops out at 24 cores, buying a 96-core socket for it is buying three quarters of a processor it cannot use. That is a decision made by whoever specifies the server, and it is currently being made by somebody who has never opened the licensing guide.

I should be careful with the register here, because none of this was done to anybody. Per-core terms were written when core counts moved slowly, in good faith, against a curve that then bent, and a vendor repricing downward as fast as silicon improved would be handing away most of its revenue for reasons its shareholders would not accept. The conflict is structural. Nobody defected, and there is no villain to name.

What I keep returning to is the sentence at the top, which is not really about licensing at all. Whatever a vendor decides to count, your engineers will eventually build around, quietly, one locally reasonable decision at a time, and without ever writing the word license on a diagram. Some years from now somebody will find a cluster cut into an odd shape and no explanation for it anywhere. The explanation is that a chip got wider than a contract expected.