Oracle sells the same database per user and per processor, and the cheaper metric flips at a calculable point driven by the 25 NUP per processor minimum and the core factor. This page gives you the arithmetic, the sequencing, and the internal versus internet-facing rules so you stop overpaying 20 to 50 percent on the wrong metric.
Oracle sells the same database per user and per processor, and the cheaper metric flips at a calculable point driven by the 25 NUP per processor minimum and the core factor. This page gives you the arithmetic, the sequencing, and the internal versus internet-facing rules so you stop overpaying 20 to 50 percent on the wrong metric.
Every Oracle Database estate carries the same buried question: is this server cheaper licensed by Named User Plus (NUP) or by Processor. The answer is not a judgment call. It is a calculation that flips at a defined threshold, and the threshold is set by Oracle's own minimums, not by your headcount. In 25 years across the negotiation table, the single most common overpayment we see is an estate that picked NUP when it had 30 users on a two-socket box, grew to 90 users, and never rebuilt the model. The metric that was correct at 30 users became a 30 to 50 percent penalty at 90, and Oracle has no obligation to tell you.
The list prices you are working against, current for 2026, are $47,500 per Processor and $950 per NUP for Enterprise Edition, and $17,500 per Processor and $350 per NUP for Standard Edition 2. Every one of those numbers then carries annual Premier Support at 22 percent of net license fee, which across a five year horizon quietly exceeds the license itself. That support tail is why the metric choice compounds: you are not choosing a one-time cost, you are choosing the base that 22 percent per year rides on for the life of the deployment. Fixing the metric before you sign is worth far more than any discount you negotiate on the wrong metric.
The NUP versus Processor decision flips at the minimums. It is arithmetic, and Oracle has no duty to tell you which side you are on.
Enterprise Edition carries a floor of 25 Named User Plus per Processor license the hardware would require. Standard Edition 2 uses a different floor of 10 NUP per server. Oracle bills the higher of your real user count or the floor, so the floor is what makes NUP expensive on large hardware even when your actual population is small. The order of operations is where most in-house models go wrong, and getting it wrong doubles the bill.
The floor applies after the core factor, not before. You first convert cores to Processor licenses using the Core Factor Table, then multiply that Processor count by 25. Oracle's own Database Licensing documentation (doc 070584) confirms that product minimums where the minimums are per processor are calculated after the number of processors. Getting this sequence right is the difference between a defensible position and an eleven percent-to-double overpayment. Our worked walkthroughs live in the 25 NUP-per-processor minimum with server examples page.
| Server | Cores | Core factor | Processor licenses | NUP floor (× 25) | Floor cost at EE list |
|---|---|---|---|---|---|
| 2 × 16-core Xeon | 32 | 0.5 | 16 | 400 | $380,000 |
| 2 × 8-core Xeon | 16 | 0.5 | 8 | 200 | $190,000 |
| 1 × 32-core EPYC | 32 | 0.5 | 16 | 400 | $380,000 |
| 2 × 32-core Xeon 6 E-core | 64 | 0.5 | 32 | 800 | $760,000 |
The trap in that table is the last row. Same rack unit, same two sockets, but core density has driven the count to 800. The core factor never moved off 0.5. Core density did. Intel Xeon 6 E-core parts now reach 144 cores per socket, so your next hardware refresh will inflate the NUP floor again unless you price it before you buy the tin, not after.
The list-price rule of thumb is clean: below roughly 50 users per Processor equivalent, NUP is likely cheaper. Above 50 users per Processor equivalent, Processor licensing wins. Note that this is 50 users per Processor equivalent, which is double the 25 minimum, because the break-even is where the sum of your NUP licenses at $950 each equals the flat Processor price of $47,500 (47,500 divided by 950 equals 50). Below that per-Processor-equivalent count, you buy fewer than 50 NUP per Processor and pay less than the Processor line. Above it, you buy more than 50 NUP and Processor is cheaper.
Two subtleties change the number. First, the 25 minimum sets a floor you cannot go below, so any server with fewer than 25 actual users per Processor equivalent still pays for 25. That means the real economically active range for NUP is between 25 and 50 users per Processor equivalent. Below 25 you are paying the floor and getting no benefit from a smaller population. Above 50 you should already be on Processor. Second, this whole model runs on list. At negotiated prices, which sit well below list for both metrics in enterprise deals and often differ between the two metrics, the crossover shifts. Rebuild the crossover with your actual negotiated per-unit prices, not the price list.
| Users per Processor equivalent | NUP cost per Processor equiv (EE list) | Processor cost (EE list) | Cheaper metric |
|---|---|---|---|
| 10 (below floor) | $23,750 (25 floor) | $47,500 | NUP |
| 25 (at floor) | $23,750 | $47,500 | NUP |
| 40 | $38,000 | $47,500 | NUP |
| 50 (break-even) | $47,500 | $47,500 | Either |
| 75 | $71,250 | $47,500 | Processor |
| 100 | $95,000 | $47,500 | Processor |
NUP only earns its keep between 25 and 50 users per Processor equivalent. Below 25 you pay the floor for nothing. Above 50 you are overpaying versus Processor.
Treat this as a template your asset team runs every time hardware or headcount changes. It is deliberately mechanical so the answer does not depend on who runs it.
Two counting errors reliably break Step 5. First, non-human users are real users. Each batch job, sensor feed, integration account, and monitoring tool that accesses Oracle directly counts as one NUP, a point we expand in counting non-human named users. Second, NUP is not concurrent licensing. You cannot license 100 NUP for a rotating population of 200 people on the theory that only 100 are ever logged in at once. Oracle counts the total authorised population, not the peak concurrent number.
The crossover math above only applies where you are permitted to use NUP at all, and that permission stops at the edge of your controlled user base. NUP is unavailable for any environment where users cannot be counted: web-facing portals, multi-tenant SaaS, and any third-party application where the population is not knowable to the licensee. If the system is customer-facing or the user base is not tightly controlled, you must use Processor licensing, because Processor permits an unlimited number of users to access the software. Using NUP for an uncountable external population is not a pricing choice, it is a direct contract violation, and audits routinely reclassify those deployments as Processor after the fact. The full explanation sits in why Oracle won't let you use NUP on internet-facing systems.
This is where the crossover stops being an optimisation and becomes a liability question. Consider the two ends of the spectrum. A 50-person internal team accessing Oracle directly holds a legitimate 50-NUP position, and the crossover model tells them NUP is correct if the server needs one Processor. Put a web application in front of the same database serving 100,000 external customers and the honest NUP count is 100,000, which at list is $95M. Nobody licenses that. You license Processor. The lesson is architectural: draw a hard boundary between internal countable systems, where you run the crossover, and internet-facing systems, where the crossover does not exist and Processor is the only compliant option.
Buyers often assume that funneling users through a middle tier, a TP monitor, an application server, or a connection pool, reduces the NUP count to the number of pooled connections. It does not. Oracle's rule is that if multiplexing hardware or software is used, all users at the multiplexing front end must be counted. The pool is invisible to the count. This is the mechanism by which a modest internal deployment can balloon: architects see 20 database sessions and license 20 NUP, while Oracle counts the 4,000 people who reach the front end. We cover the mechanics and the audit exposure in the multiplexing and front-end rule analysis.
Practically, multiplexing is a signal that you are drifting toward an uncountable population, which is the same signal that pushes you toward Processor. If you cannot enumerate and defend the users at the front end, you have failed the NUP eligibility test, and the crossover model no longer applies. Build a defensible user list before you commit to NUP; our reconciliation approach is in building a defensible named user list.
Two contract rules amplify whatever metric you pick. First, you cannot mix metrics on a single deployment. A database server, cluster, or shared environment must be entirely Processor or entirely NUP. You do not get to license the base per Processor and the options per NUP to shave cost. Second, Database options and packs, Partitioning, Advanced Security, Diagnostics Pack, and the rest, follow the metric of the underlying database. If the database is Processor, every option is Processor. If it is NUP, every option carries the same NUP count including the 25-per-Processor floor. This means a cheap-looking NUP base can drag three or four options behind it at the same inflated floor, and the crossover you calculated on the base alone understated the real number. The options and packs must match the database page shows how this compounds. For the edition-level decision that sits above all of this, see Oracle SE2 versus Enterprise Edition.
Options follow the base metric. A cheap-looking NUP base drags Partitioning and Diagnostics behind it at the same 25-per-Processor floor.
Run the seven-step calculation on every Oracle Database server in the estate, using your negotiated per-unit prices rather than list. Flag any NUP server sitting above 50 users per Processor equivalent as an overpayment candidate and model the switch to Processor at your next renewal or true-up, which is a natural, penalty-free moment to change metric. Flag any NUP server that touches an internet-facing or multiplexed front end as a compliance risk, not a pricing question, and plan the move to Processor before an audit forces it at Oracle's terms.
Two figures anchor the priorities. Estates that never revisit the metric overpay 20 to 50 percent when a population grows past the crossover. And the support tail at 22 percent per year means every dollar of metric error compounds annually for the life of the deployment. The remediation is cheap: a spreadsheet, the Core Factor Table, and a defensible user count. The inaction is expensive. Run the numbers, then decide with the vendor once you already know the answer. For the counting rules that underpin the whole exercise, start with the pillar on NUP counting rules, minimums, and audit traps, and use the metric decision download to model your own crossover.
At list prices, Processor becomes cheaper above roughly 50 users per Processor equivalent, because 50 NUP at $950 each equals the $47,500 Processor line for Enterprise Edition. Below 50 users per Processor equivalent, NUP is usually cheaper, but the 25 NUP minimum means you pay for at least 25 per Processor regardless. Always recalculate the crossover using your negotiated prices, which shift the break-even.
After. You first convert cores to Processor licenses using the Core Factor Table, then multiply that Processor count by 25. Oracle's own Database Licensing documentation confirms product minimums are calculated after the number of processors. A 32-core x86 server at a 0.5 core factor is 16 Processor licenses, so the floor is 16 × 25 = 400 NUP, not 800.
No. NUP is unavailable for any environment where the user population cannot be counted, including web portals and customer-facing systems. Internet-facing databases must be licensed by Processor, which permits unlimited users. Using NUP for an uncountable external population is a direct contract violation, and audits reclassify these deployments as Processor.
No. Oracle's multiplexing rule requires you to count all users at the multiplexing front end, not the number of pooled connections. A 20-connection pool serving 4,000 people counts as 4,000 NUP. If you cannot enumerate the users behind the front end, you have failed the NUP eligibility test and should be on Processor.
Yes. Non-human operators, including batch jobs, integration accounts, monitoring tools, and service accounts, each count as one NUP if they access Oracle directly. Leaving these out of the count is a common audit finding. Include every automated identity when you run the crossover calculation.
No. You cannot mix metrics on a single deployment, and options and packs must follow the metric of the underlying database. If the database is NUP with a 25-per-Processor floor, every option carries the same NUP count and floor. This compounding is why a cheap-looking NUP base can end up more expensive than Processor once options are included.
Oracle sells the same database per user and per processor. The 25 NUP per processor minimum, the 50 user break-even, and how to choose the metric that fits the workload.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
