Oracle's 25 Named User Plus per Processor minimum is a contractual floor, not a guideline, and it is calculated from processor counts you often cannot reduce. This article shows the exact order of operations, five worked server examples at 2026 list prices, and where the floor quietly stops being cheaper than Processor licensing.
Oracle's 25 Named User Plus per Processor minimum is a contractual floor, not a guideline, and it is calculated from processor counts you often cannot reduce. This article shows the exact order of operations, five worked server examples at 2026 list prices, and where the floor quietly stops being cheaper than Processor licensing.
The 25 Named User Plus per Processor minimum for Database Enterprise Edition does not live in a whitepaper, an FAQ, or a partner slide. It sits in the Oracle License Definitions and Rules document that is incorporated into your ordering document by reference (the olsadef family of PDFs), which states that the customer is "responsible for ensuring that the named user plus per processor minimums are maintained for the programs contained in the user minimum table." The table then gives the minimum number of licenses required, and separately requires that all actual users be licensed. That distinction matters more than most buyers realize during an audit: the floor and the headcount are two independent tests you must pass at the same time, not alternatives. Oracle's own partner licensing training states the position plainly: you owe the minimum, or the number of users and non-human-operated devices accessing the database, whichever is greater.
This is why the negotiation posture you use against Oracle's policy documents does not transfer here. Partitioning policy and cloud licensing policy are non-contractual statements of Oracle's current practice, which is exactly why experienced buyers push back on them and occasionally win. The 25 NUP floor is ordering document text. There is no equitable argument, no "this is only policy" argument, and no reasonable-use argument. If you want relief, you buy it in the contract with an amendment, not in the audit meeting.
Pin the definition too, because the floor is only half the exposure. A NUP is an individual authorized to use the programs regardless of whether they are actively using them, and a non-human-operated device that can access the programs counts as an additional NUP on top of every authorized individual. Read that alongside our detailed treatment of Oracle NUP counting rules and per-processor minimums before you accept any Oracle-generated count.
The 25 NUP floor is ordering document text, so there is no "that is only policy" argument available to you.
Oracle's Processor definition fixes the sequence, and the sequence changes the answer. The text requires that "all cores on all multicore chips for each licensed Program are to be aggregated before multiplying by the appropriate core processor licensing factor and all fractions of a number are to be rounded up to the next whole number." Three words do the work: aggregated, before, and rounded up. So the calculation runs in four steps, in this order and no other: aggregate all cores running the licensed program, multiply the aggregate by the core factor, round the single resulting fraction up to the next whole number, then multiply that processor count by 25 to get the NUP floor.
The mechanical insight buyers keep missing is that the core factor never touches the NUP count directly. It only sets the processor number from which the floor is derived. A 0.5 factor halves your processor requirement, and therefore halves your floor, but it does nothing to your actual user headcount, which still has to be licensed separately if it is higher.
Rounding position is where the money leaks. Because rounding happens once per program per aggregation rather than once per server, odd core counts behave badly. Take 41 aggregated cores at factor 0.5: that is 20.5, which rounds up to 21 Processor licenses, which sets the floor at 525 NUP rather than 500. Half a core just added 25 NUP, or $23,750 at the 2026 list price of $950 per NUP, plus roughly $5,225 a year in support at 22 percent. In our negotiation experience that single fraction is the cheapest thing to engineer away: dropping one core, or hard-partitioning to 40, removes the step entirely. Model it against the crossover logic in our Named User Plus or Processor metric decision before you finalize any core layout.
All five examples below use the August 3, 2026 Oracle Technology Global Price List: Database Enterprise Edition at $950.00 per Named User Plus and $47,500.00 per Processor, with support at 22 percent of net. The order of operations is fixed by the Processor definition itself: aggregate cores, multiply by the core factor, round the fraction up once, then multiply the resulting processor count by 25. Notice the ratio that governs every row: NUP is priced at exactly one-fiftieth of Processor, so the 25 NUP floor is always half the cost of Processor licensing at list, and the real question is never "is the floor expensive" but "does my actual headcount sit above 50 users per Processor." Three of the five configurations below have the floor overriding real headcount, which is roughly the hit rate we see in Oracle NUP counting and per-processor minimum reviews across mid-sized estates.
| Configuration | Physical cores | Core factor | Processors (rounded up) | 25 x Processor floor | Actual users | Licensable NUP | NUP list at $950 | Processor list at $47,500 |
|---|---|---|---|---|---|---|---|---|
| 4-core Intel Xeon, single socket | 4 | 0.5 | 2 | 50 | 30 | 50 | $47,500 | $95,000 |
| 2-socket x86, 10 cores per socket | 20 | 0.5 | 10 | 250 | 300 | 300 | $285,000 | $475,000 |
| 2-socket Intel Xeon, 16 cores per socket | 32 | 0.5 | 16 | 400 | 240 | 400 | $380,000 | $760,000 |
| Single POWER9 frame, 32 cores | 32 | 1.0 | 32 | 800 | 400 | 800 | $760,000 | $760,000 |
| Aggregated estate, 41 cores across servers | 41 | 0.5 | 21 | 525 | 380 | 525 | $498,750 | $997,500 |
Read the rows in order. Row one is the classic under-licensing failure: 30 users on a 4-core box, the customer buys 30 NUP, and the audit finds 2 Processors times 25 equals 50, leaving them 20 licences short at $19,000 list plus backdated support. Row two is the only row where the floor is irrelevant, because 300 actual users exceed the 250 floor; here the real risk is metric choice, not the minimum, and Processor at $475,000 is the wrong answer only until user growth passes 500. Row three is where the floor becomes the entire bill: 240 real users, 400 licensable NUP, and $152,000 of list spend purchased purely to satisfy a contractual floor. Row four is the collapse point. POWER9 carries a 1.0 core factor, so 32 cores produce 32 Processors, the floor lands at 800 NUP, and 800 times $950 equals $760,000, identical to 16... to be precise, identical to 32 Processors at $47,500. When NUP and Processor cost the same money, the NUP metric is strictly worse: you keep the counting obligation, the audit exposure on service accounts and non-human devices, and the growth ceiling, for zero saving. Buy Processor.
When the floor and the Processor price land on the same number, you are paying full Processor money for the privilege of counting users forever.
Row five deserves its own note because it is the rounding trap. Forty-one aggregated cores times 0.5 equals 20.5, which rounds up to 21 Processors, which sets the floor at 525 NUP. That final half core costs you 25 NUP, or $23,750 at list, plus $5,225 of annual support at 22 percent. We have seen this triggered by a single decommissioned-but-still-installed dev instance contributing one core to the aggregation. Before you accept any floor number in an audit finding, force the vendor to show the core inventory that produced the aggregation, and strip out anything not actually running the program. Two practical levers apply to every row: an individual counts once regardless of how many databases or servers they access, which materially reduces multi-server totals, and you cannot mix metrics inside one deployment, so the floor is computed per licensed environment rather than blended across the estate. Work the metric decision deliberately using the NUP versus Processor decision framework rather than defaulting to whichever line the reseller quoted.
The 25 NUP floor is a multiplier applied to a processor count, and that count is only as good as the core factor input. The factor never reduces a NUP number directly; it sets the processor figure the floor is derived from. Move from 0.5 to 1.0 on identical core counts and both the processor count and the floor double. The factors that matter in practice: Intel and AMD x86 at 0.5, IBM POWER10 at 0.75, POWER8 and POWER9 at 1.0, SPARC T series between 0.25 and 0.5 depending on model, SPARC S, M and Z series at 1.0, Ampere Altra, AltraMax and AmpereOne at 0.25, all other ARM at 1.0, and anything not listed defaulting to 1.0. The January 28, 2026 change log added Intel Xeon 69xxP, 67xxE, 67xxP, 65xxP and 63xxP (including -B variants) at 0.5, along with clarified AMD EPYC and Opteron entries. If you refreshed onto current-generation Xeon in 2025 and your compliance position was built on an older table copy, re-run it: the entries now exist and the 0.5 factor is defensible.
The most expensive self-inflicted error we encounter is not factor selection at all. It is ITAM discovery scripts feeding logical processor counts into the calculation. Hyper-Threading reports 64 logical CPUs on a 32-core Xeon, and an unchecked script turns a legitimate 16-Processor, 400 NUP floor into a paper 32-Processor, 800 NUP floor, a $380,000 list overstatement that you then hand to Oracle as your own evidence. Check every extract for physical core counts, socket counts and CPU model strings before it leaves your organisation, and never submit a discovery output you have not reconciled against the published factor table yourself.
The floor does not stop at the database line. Oracle's License Definitions and Rules require that option and pack license counts match the associated database, and where those options are bought on Named User Plus you must maintain a minimum of 25 NUP per Processor per associated database. That language covers Real Application Clusters, Partitioning, OLAP, Data Mining, Spatial, Advanced Security, Label Security, and Diagnostics Pack, and the same matching principle is applied to Multitenant. The practical effect is compounding, not addition. Take the 16-Processor box from the worked examples, two sockets of 16 cores at core factor 0.5, which produces a 400 NUP floor on Enterprise Edition. Every option installed on that database inherits the same 400 NUP floor, regardless of how many people actually use the feature. Multitenant at $350 NUP list adds $140,000. RAC at $460 NUP list adds $184,000. Add Diagnostics Pack and Partitioning and you are past the Processor cost of the database itself, entirely because of the floor rather than because of user demand. In 25 years of negotiating this vendor, the pattern we see repeatedly is a customer who priced options against a 40-user reality and then discovered the contract prices them against a 400-user minimum.
Every option on that database inherits the same 400 NUP floor, whether forty people use it or four hundred.
The buyer move is mechanical and it happens before the audit letter, not after. Inventory which options and packs are actually installed on each Enterprise Edition instance, separate installed from used, and deinstall anything that is not carrying a business requirement. Diagnostics and Tuning Pack exposure through casual Enterprise Manager or AWR access is the single most common finding, and it is expensive precisely because the floor multiplies it. Our Named User Plus counting rules and audit traps guide sets out the evidence you need to keep on deinstallation dates.
Strip the decision down to one ratio. On Enterprise Edition, Oracle lists NUP at $950 and Processor at $47,500, exactly one-fiftieth. That means Processor licensing wins past 50 real users per licensed Processor, and the 25 NUP minimum commits you to half of that spend before a single person logs in. Run the crossover on a 2-Processor box. Twenty real users still costs 50 NUP, roughly $47,500 list, which is the same as one Processor license and half the Processor cost of the box for a quarter of the user population. One hundred users costs $95,000, which matches the 2-Processor price exactly, so you have paid Processor money without Processor rights. Three hundred users at $285,000 is three times the Processor cost for a machine you already own. Anywhere between 25 and 50 users per Processor you are paying for entitlement nobody consumes, and past 50 you are actively overpaying versus the alternative metric.
The recurring cost is what makes this a governance issue rather than a purchasing footnote. Support runs at 22 percent of net license fees, so an inflated floor is not a one-time error, it is an annuity paid to Oracle every year until you restructure the contract. On Enterprise Edition, a single discount point is worth roughly $2.10 in recurring support terms, which means the negotiation value of removing 150 phantom NUP licenses compounds well past the first invoice. Repricing rules on partial terminations mean you rarely get that money back cleanly once it is in the support base.
One constraint shapes the remedy. A single installation must be licensed entirely on NUP or entirely on Processor, so you cannot cover 40 users with NUP and the rest with a Processor license on the same database. Separate environments can carry different metrics, and that is the lever: keep genuinely small, restricted-population instances on NUP and move anything with growing or unpredictable access onto Processor before the floor overtakes it. Model both metrics per environment, not per estate, using the framework in our Named User Plus or Processor metric decision resource, and re-run it whenever core counts or user populations move.
Run this before renewal, before a consolidation project, and certainly before you answer an audit questionnaire, because every step below is something Oracle will compute for you if you do not compute it first.
Document each step with dated evidence. At 22 percent support on net, an inflated floor compounds annually, not once.
Per processor licence, calculated after core-factor multiplication and rounding up. A single physical server with 16 licensable Processors carries a 400 NUP floor, not 25. The floor scales linearly with the processor count, which is why hardware sizing drives the licence bill more than user headcount does on Enterprise Edition.
Yes. Four physical cores at a 0.5 core factor equals 2 Processor licences, and 2 x 25 gives a 50 NUP floor. Buying 30 NUP leaves you 20 licences short and non-compliant, which is one of the most frequently cited findings in Oracle audit reports. You always license the higher of the contractual floor or your actual authorized user and device count.
No. The core factor only reduces the number of Processor licences, and the NUP floor is then derived from that reduced processor number. A 32-core Intel Xeon at 0.5 gives 16 Processors and a 400 NUP floor, while the same 32 cores on IBM POWER9 at 1.0 gives 32 Processors and an 800 NUP floor. The factor sets the multiplier input, nothing more.
They do. Oracle's License Definitions require option and pack quantities to match the associated database, and where licensed by NUP you must maintain at minimum 25 NUP per Processor per associated database. A 400 NUP floor on the database therefore forces 400 NUP on every option installed on it, regardless of how few people use the feature. Deinstalling unused options before an audit is the only reliable mitigation.
Not on the same installation. Each deployment must be licensed entirely by NUP or entirely by Processor. You can run one server under NUP and a separate, distinct environment under Processor, but you cannot split a single database instance across both metrics to dodge the floor.
At roughly 50 real users per licensed Processor, because Oracle prices NUP at exactly one-fiftieth of the Processor price on EE ($950 versus $47,500 at 2026 list). The 25 NUP floor means you are already committed to half of Processor cost with zero users, so the practical window where NUP saves money is narrower than most buyers assume. Model it per environment, not per estate.
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.
