The decision rule is countability first, arithmetic second: Named User Plus is only available where every human and device that touches the database — directly or through any intervening layer — can be identified and counted, and it is only economic where that population is small relative to the hardware. Everywhere else, including every uncountable or internet-facing population, the Processor metric is the answer by definition, and the real work is counting cores correctly under core factors, virtualization policy and cloud rules.
Published 25 February 2026 · Last reviewed 27 April 2026
Oracle's perpetual license catalogue prices Database, options, packs and much of the middleware stack on one of two metrics. Named User Plus licenses the population authorized to use the program — every named individual and every non-human-operated device, counted wherever they sit in the architecture. Processor licenses the hardware the program runs on: physical cores, multiplied by the core factor Oracle assigns to the chip family, with no reference to how many people use the system or how hard it works.
The metrics are alternatives for the same products, and the choice is made at purchase — which is precisely why it deserves more deliberation than it usually gets. The decision fixes not just the price of the initial order but the shape of the support stream that follows it, the compliance evidence you will need to produce for the life of the license, and the way the position behaves when the architecture changes underneath it. A metric chosen for a 2016 deployment pattern is a common root cause of 2026 audit findings.
It also pays to be clear what this choice is not. It is not Oracle's subscription-era employee metric — that belongs to the Java comparison — and it is not the editions question, which has its own fork in SE2 vs EE. This is the classic perpetual-license decision, and it remains live: every new on-premise order, every ULA certification landing into fixed counts, and every BYOL move into cloud rests on one of these two metrics.
This guide is general information about Oracle's license metrics, not legal or licensing advice for your situation; definitions and minimums are set by your agreement and Oracle's current price list documents. It names no firms; the firm directory lists Oracle-capable advisors with balanced pros and cons, listed, not ranked.
Three rules turn an apparently simple user count into the place Oracle audits most reliably find money. First, the multiplexing rule: users are counted at the front end of the access chain. Application servers, connection pools, integration buses and service accounts do not compress the count — every human or device upstream of the pooling layer counts as if it connected directly. Second, devices count: a non-human-operated input — a sensor network, a scanner fleet, an upstream system pushing batch feeds — is a countable user. Third, the minimums: Database Enterprise Edition carries a floor of 25 NUP per Processor license the hardware would require (after core factor), and Standard Edition 2 a floor of 10 NUP per server. The floor applies even when the genuine population is smaller; when the genuine population is larger, you license the population.
Worked through honestly, the minimum calculation forces you to do the Processor arithmetic anyway: count the cores, apply the core factor, derive the hypothetical Processor licenses, multiply by 25. A two-socket, 16-core-per-socket x86 server at the common 0.5 core factor implies 16 Processor licenses — and therefore a 400-NUP floor for EE before a single real user is counted. NUP only undercuts Processor where the authorized population sits comfortably below that arithmetic, which in practice means contained internal systems: development and test, back-office applications with stable named populations, departmental workloads on modest hardware.
The Processor count starts mechanically: physical cores running the program, multiplied by the core factor for the chip — 0.5 for the Intel and AMD x86 families that dominate estates, 1.0 for IBM POWER, fractional values for various SPARC parts. The mechanics end there, and policy begins.
Virtualization is where the metric's risk concentrates. Oracle's partitioning policy distinguishes hard partitioning (accepted as a way to cap licensable cores: approved technologies and Oracle's own engineered-system mechanisms) from soft partitioning (not accepted: hypervisor-level vCPU limits, VMware among them). Oracle's audit position has historically extended the licensable boundary from the VM to the host to — in widely reported disputes — the whole cluster or estate where live migration is enabled. Two facts belong side by side here, stated factually: the partitioning policy is a non-contractual policy document, and customers with well-drafted agreements have contested its broadest readings; and Oracle applies it consistently in audit practice, so an estate that ignores it is choosing a dispute. This is information, not advice — what your signed agreement says governs, and reading it precisely is the first task of any effective license position exercise.
Authorized clouds run on their own counting document: in AWS and Azure, Oracle's cloud licensing policy counts vCPUs rather than factored physical cores — two vCPUs per Processor license where hyper-threading is on — with no core factor applied. The same workload can therefore carry a different license count on-premise, in a hyperscaler, and in OCI, which is the arithmetic behind the BYOL versus license-included decision and worth fixing in writing before any migration rather than after it.
| MECHANIC | NAMED USER PLUS | PROCESSOR |
|---|---|---|
| Unit counted | Named humans plus non-human devices, counted at the multiplexing front end | Physical cores × core factor; vCPU rules in authorized clouds |
| Availability condition | Population must be identifiable and countable | Always available; the default for uncountable populations |
| Floors | 25 per Processor-equivalent (EE); 10 per server (SE2) | None beyond the count itself |
| Scales with | Headcount, integrations, device fleets | Hardware refreshes, core density, cluster design |
| Compliance evidence | Authorized-user registers, joiner/leaver hygiene, interface inventories | Hardware records, hypervisor configuration, partitioning posture |
| Typical audit finding | Uncounted indirect users and devices behind middleware | Under-licensed virtualized clusters; DR and standby nodes |
| Where it fits | Contained internal populations on modest hardware; dev and test | Production, customer-facing, integration-heavy and virtualized estates |
On economics: Oracle's price list sets a fixed ratio between the two metrics, and at list the break-even lands — indicatively — around fifty named users per Processor license for Enterprise Edition. Below that population the NUP route can be materially cheaper; near or above it, Processor wins on price and removes the counting burden. But the published ratio is the start of the analysis, not the end: discounts move the crossover, support streams inherit the chosen metric forever, and a population that is countable today may not stay countable as integrations accumulate.
Named User Plus earns its place in environments that are genuinely bounded: a development and test landscape with a known engineering population, a finance application used by a named department, a contained workload on hardware small enough that the 25-per-processor floor does not swallow the saving. The strongest NUP positions share two features — a population registry someone actually maintains, and an architecture without silent feeders, because each new integration quietly adds countable devices.
Processor earns its place wherever counting is impossible or merely unwise: production systems behind web front ends, anything customer-facing, estates with deep middleware chains, and — increasingly decisive — virtualized platforms, where the licensing question is about cores and clusters regardless of which metric the paper carries. It is also the metric ULA certifications land on for server estates, and the currency of BYOL conversations with every cloud.
The hybrid is the norm, not the exception. Mature Oracle estates run Processor in production and NUP in non-production, reviewed at every hardware refresh and every architecture change. The review matters more than the original choice: core-dense refreshes inflate Processor counts at the same time as integration sprawl inflates NUP counts, and which pressure dominates is an empirical question an Oracle licensing advisory engagement answers with a deployment inventory rather than a rule of thumb.
Against NUP positions, the recurring findings are structural rather than careless: indirect users behind an application server nobody counted; device fleets and batch feeds treated as “the interface” rather than as users; floors never recalculated after a hardware refresh quietly raised the Processor-equivalent baseline; and leavers who remain authorized because deprovisioning lagged. The defense is unglamorous — a maintained register of authorized users and devices, an interface inventory, and floor arithmetic redone whenever hardware changes.
Against Processor positions, the findings concentrate on virtualization and topology: clusters where Oracle workloads could run, counted by the auditor as places they must be licensed; disaster-recovery and standby nodes outside the narrow remote-mirroring allowance; options and packs enabled on cores the base license covers but the option count does not. The defense is configuration evidence — host affinity, cluster boundaries, feature-usage data pulled before Oracle pulls it. When a position is contested, the gap between Oracle's policy documents and the signed contract is exactly the terrain audit defense firms work, and the earlier the contract is read against the policy, the cheaper the answer.
At purchase time, the negotiation points follow from all of the above: definitions of the counted population for NUP-heavy orders, partitioning and cloud-counting language for Processor-heavy ones, metric-migration paths for the day the architecture moves, and pricing that anticipates the support stream rather than the first invoice. None of it is exotic; all of it is easier before signature than after.
The editions fork that pairs with the metric fork →
When unlimited replaces counting altogether →
What the metrics are worth in cloud →
How to pick the firm for this work →
Firms that model metric decisions →
Every field guide on the site →
For Oracle Database Enterprise Edition, 25 Named User Plus per Processor license — calculated after the core factor adjustment — even if fewer people actually use the system. For Standard Edition 2 the minimum is 10 NUP per server. The minimum is a floor on what you must buy, not a cap on what you must count: if the real authorized population is higher than the floor, you license the real population.
No. Oracle’s multiplexing rule counts users at the front end of the chain: every individual or device that accesses the database through an application server, middleware layer, connection pool or batch interface must be counted as if they connected directly. A web application with one service account and ten thousand human users behind it needs ten thousand NUP — or, far more practically, the Processor metric.
Yes, across environments. A common pattern licenses production on Processor — where populations are large or uncountable — and development, test or other contained environments on NUP. Within a single server or environment you apply one metric to a given program, and options and packs must match the metric and count of the underlying database licenses on that server.
This is the highest-stakes counting rule in the comparison. Oracle’s partitioning policy treats common hypervisor-level limits — VMware vCPU caps included — as soft partitioning, which it does not accept as a means of limiting the licensable core count; Oracle’s position is that the physical cores available to the workload must be licensed, which in audit practice has extended to entire clusters. Hard partitioning technologies on Oracle’s approved list, and Oracle’s own engineered systems mechanisms, can cap the count. The policy document is non-contractual, and disputes over its reach are a recurring audit battleground — your signed agreement is what governs.
Whenever the user population cannot be identified and counted — public websites, customer-facing portals, APIs consumed outside the organisation. Oracle’s own licensing definitions point such environments to the Processor metric, because Named User Plus presumes a countable, named population. Internet-facing workloads on NUP are one of the most common audit findings in Oracle estates.
Yes. Named User Plus covers humans and non-human-operated devices: sensors, scanners, machines and upstream systems that feed the database count as users, and a device-fed system with automated inputs can need substantially more NUP than it has human users. Batch data transfers from other systems fall under the same counting logic — another reason device-heavy or integration-heavy environments tend to land on Processor.
Choosing the metric — and defending the choice when the architecture has moved — is exactly what an Oracle licensing advisor is for. The directory lists the firms that do this work, with balanced pros and cons, listed, not ranked.
Tell us the vendor, the service you need and where things stand, and we will route your brief to firms that genuinely cover that combination. The directory and matching are free for buyers, no vendor ever sees your brief, and we add no markup.
Our weekly dispatch on vendor audit programs, regional developments and one buyer move. Subscribe to The Licensing Radar.