COMMERCIAL LICENSING
Per core and per node licensing metrics explained.
The metric a vendor uses to meter a commercial license decides how your bill scales. Per core and per node licensing metrics explained: how each one is counted, where the cost quietly hides, and how to baseline your usage so the figure comes from your data rather than theirs.
With per core and per node licensing metrics explained plainly, a commercial open source license stops being a mystery and becomes a model you can control. When a project such as Redis, Elasticsearch, or a HashiCorp tool requires a paid license for the way you run it, the price is almost never a flat fee. It is metered, and the metric chosen decides how the cost grows as your deployment changes. Two metrics dominate: per core and per node. Understanding how each is counted is the first step to making sure you pay for what you run and nothing more. None of this is legal advice, and the question of whether your use requires a license belongs with your own counsel.
What per core licensing actually counts
Per core licensing charges for each processor core on which the software runs. The appeal to a vendor is that it scales with compute power, so a buyer running heavier workloads pays more. The appeal to a buyer is precision: you pay in proportion to the capacity you actually use. The complication sits in the definition of a core. Physical cores and virtual cores are not the same thing, and the mapping between them in a virtualised or cloud environment can swing the count significantly. A contract that counts virtual cores on a host that overcommits its physical cores can bill you for capacity that does not exist in any meaningful sense. The metric is only as fair as its definition, and the definition is where attention belongs.
What per node licensing actually counts
Per node licensing charges for each server or instance running the software, regardless of how large that node is. A small instance and a large one count the same. This favours buyers who run dense, powerful servers, because one node license covers many cores. It works against buyers who run many small instances, since each one draws a full node charge. The definition of a node matters as much as the definition of a core. Does a container count as a node, or the host beneath it? Does a node that exists only during an autoscaling burst count for the full period or only while live? These questions decide the bill, and they are rarely settled in the vendor's first draft.
Which metric is cheaper for you
There is no universal answer, only the answer for your topology. Per node tends to favour buyers running fewer, larger servers, because the cores inside each one come free under a single node charge. Per core tends to favour buyers running many small instances, where a node count would multiply quickly. The vendor usually proposes whichever metric bills your specific deployment highest, because they can see your architecture and model it. The defence is to model both metrics against your real footprint before you accept either, so you negotiate on the one that reflects how you actually run. The wider context of how these models are priced sits in commercial open source pricing benchmarks.
Where the cost hides
The headline rate per core or per node is the visible part. The cost hides in the counting rules. Watch whether non production environments count, because development, staging, and disaster recovery nodes can double or triple a naive estimate. Watch how autoscaling and burst capacity are treated, since a metric counted at peak rather than average can bill you for a spike you ran for an hour. Watch how virtual cores map to physical ones, and whether hyperthreading is counted. Watch whether the figure is measured continuously or sampled, and how often. Each of these definitions can multiply the bill without changing a single thing about what you actually run. A buyer who reads only the rate and not the rules has not read the contract.
Baseline first, then negotiate
The discipline that controls a metered license is the same one that controls any usage based purchase: measure first. An accurate usage baseline tells you how many cores or nodes you genuinely run, across all environments, at peak and at average. With that number in hand, the count comes from your data rather than the vendor's, and you can challenge any figure that does not match. The baseline also feeds your walk away analysis, because it tells you what a fork migration would cost in like for like terms. Without it, you are negotiating against the vendor's anchor with nothing of your own to push back with, a position examined in leverage in open source commercial negotiations.
Pin the definitions and cap the growth
Once you have chosen a metric, fix its definition in the contract in your own words, not the vendor's loose phrasing. State exactly what counts as a core or a node, which environments are included, and how bursts are handled. Then cap how the metered figure can grow within a term, so ordinary expansion does not trigger an open ended uplift. A metric without a pinned definition is a metric the vendor can reinterpret at audit, and the renewal is where loose definitions become expensive. The multiyear effects of these choices are worked through in multiyear commercial license tradeoffs, and the common counting questions appear again in the commercial open source licensing FAQ.
The buyer side view
We baseline your usage across every environment, model both metrics against your real topology, and tell you which one bills your deployment lowest. We then help pin the definitions and cap the growth so the agreement reflects what you run today and as you scale. We are independent and paid only by you, never by a vendor or reseller, so the metric we recommend serves your budget. The full set of resources sits in the commercial licensing pillar, and we run the work through our open source commercial license negotiation service.
COMMON QUESTIONS
Questions buyers ask.
What are per core and per node licensing metrics?
They are two common ways commercial open source vendors meter a license. Per core charges for each processor core running the software. Per node charges for each server or instance regardless of its size. The metric chosen decides how your bill scales as your deployment changes.
Which metric is cheaper for a buyer?
It depends on your topology. Per node tends to favour buyers running large, dense servers, since one node covers many cores. Per core tends to favour buyers running many small instances. The vendor usually proposes the metric that bills your specific deployment highest, which is why you should model both against your real footprint.
Where does the cost hide in these metrics?
In how the metric is defined and counted. Watch how virtual cores map to physical ones, whether non production and disaster recovery nodes count, how autoscaling and burst capacity are treated, and whether the count is a peak or an average. Each definition can multiply the bill without changing what you actually run.
How do you control a usage based license?
Baseline your real usage before negotiating, so the count comes from your data rather than the vendor's. Model both metrics against your topology, pin the definitions in the contract, and set caps on how the metered figure can grow. An accurate baseline turns an open ended bill into a bounded one.
Is this article legal advice?
No. It is commercial and licensing risk analysis, not legal advice. For interpretation of license terms and contract drafting, engage your own counsel.
CONTAINMENT
Model the metric before you sign it.
Confidential commercial license negotiation support. Independent, buyer side, paid only by you.
Not ready to talk? Read the free open source license risk guides first.