Oracle Named User Plus Minimums
Named User Plus licensing carries a minimum number of users per processor that you must license even if fewer people use the database. For Enterprise Edition the minimum is 25 Named User Plus per processor, calculated on the licensable processor count after the core factor. The minimum, not the actual user count, often sets the true cost of NUP licensing.
Named User Plus looks like a usage based metric, and buyers reach for it expecting to pay for the people who actually use the database. The minimum quietly defeats that expectation. Because Oracle requires a fixed number of users per processor regardless of real usage, the minimum, not the headcount, often sets the cost. This article explains how the minimum works, when Named User Plus still wins despite it, and how it traps the unwary. It deepens the processor versus Named User Plus decision and sits under the database pillar.
What are Named User Plus minimums?
A Named User Plus minimum is the floor on the number of user licences you must hold for a given amount of hardware, irrespective of how many people use the system. Oracle sets the minimum per processor, so the more processors the database runs on, the higher the floor. For Enterprise Edition Database the figure is 25 Named User Plus per processor.
The effect is that Named User Plus is never purely a user count. It is the higher of the actual user count and the per processor minimum. A database with ten genuine users on a sixteen processor server does not owe ten licences; it owes the minimum, which is far larger. This is the first thing to internalise about the metric.
How the minimum is calculated
The calculation runs through the processor count. Start with the physical cores, apply the core factor to get the licensable processor count, then multiply by 25 for Enterprise Edition. The result is the minimum number of Named User Plus licences. You then compare it to the actual countable user population and license the higher of the two.
Because the minimum derives from the processor count, everything that changes the processor count changes the minimum. A hardware refresh that adds cores raises the floor. A move to a higher core factor processor raises it further. The minimum therefore inherits all the hardware sensitivity of Processor licensing, which is why the metric choice cannot be made without modelling both the user count and the hardware.
Why the minimum exists
The minimum exists to stop Named User Plus being used to under license large machines with small declared user counts. Without it, a customer could run a powerful server with a handful of named users and pay a fraction of the Processor price for the same compute. The minimum ties the user metric back to the hardware, ensuring that large machines carry a substantial licence cost whichever metric is chosen.
For the buyer, this means Named User Plus is genuinely advantageous only where the user population is both small and the hardware is modest. Where either the user count is large or the server is powerful, the minimum erodes or eliminates the advantage, and Processor licensing may be cheaper and simpler.
Worked examples
| Server | Processors after factor | NUP minimum | Actual users | Licences owed |
|---|---|---|---|---|
| 16 cores, 0.5 factor | 8 | 200 | 50 | 200 |
| 16 cores, 0.5 factor | 8 | 200 | 300 | 300 |
| 32 cores, 0.5 factor | 16 | 400 | 50 | 400 |
| 8 cores, 0.5 factor | 4 | 100 | 30 | 100 |
The table shows the minimum dominating in three of the four cases. Only when the actual user count rises above the floor does the real headcount drive the cost. The lesson is that the minimum is the default outcome for any database with a modest user population, and the actual count matters only above the threshold the hardware sets.
When Named User Plus still wins
Named User Plus still wins in a specific shape of deployment: a small, well defined, countable user population running on modest hardware. Development and test databases, departmental systems, and applications with a fixed internal user base often fit. In these cases the minimum is small because the hardware is small, and the user count sits below or near the floor, so the total cost is well under the Processor equivalent.
The metric also wins where the user population can be firmly capped and documented, because Named User Plus requires counting every individual and device authorised to use the database, including those accessing it indirectly through application or batch layers. Where that population cannot be counted or capped, Processor licensing removes the counting risk entirely, a trade off explored in the metric choice article.
Counting users correctly
The Named User Plus definition counts every individual person and every non human operated device authorised to use the database, whether they access it directly or through another application tier. This is the second trap after the minimum. A web application with a small administrative team but a large indirect user base can owe licences for all the indirect users, because multiplexing through a middle tier does not reduce the count under Oracle's definition.
Counting correctly therefore means tracing every path to the database, including batch jobs, integration accounts, and front end users who reach it indirectly. Undercounting here is a frequent audit finding, because Oracle counts the full authorised population and the customer often counted only the direct users. Getting this right is part of the discipline the database licensing service applies before a metric is chosen.
The buyer side view
The buyer side view of the minimum is that Named User Plus is a user metric in name only above a certain hardware size, and the decision to use it must be made by comparing the floor to the Processor price rather than by looking at the headcount alone. Calculate the minimum from the processor count, count the full authorised user population including indirect access, and choose the metric on the higher of the two against the Processor alternative. For the full metric comparison, see the processor versus Named User Plus article, the database licensing white paper, or request a consultation.
How the minimum drives audit findings
The minimum drives audit findings when a customer licenses to the actual user count and ignores the floor. Oracle recalculates the requirement on the per processor minimum, and the gap between the licensed user count and the minimum becomes the finding. This is common in estates that adopted Named User Plus to save money on a small user base without realising the hardware set a higher floor.
A second finding arises from undercounted indirect users, where multiplexing was assumed to reduce the count. Both are defended by reconstructing the correct user population and the correct minimum from the actual hardware and access paths, work that sits with the audit defence practice. The defence is stronger when the counting was done correctly at the outset rather than reconstructed under audit pressure.
Common minimum mistakes
The first mistake is licensing to the headcount and ignoring the per processor minimum, which understates the requirement on any sizeable server. The second is forgetting that the minimum scales with the processor count, so a hardware refresh silently raises the floor even if the user base is unchanged. The third is counting only direct users and assuming multiplexing reduces the obligation, when Oracle counts the full authorised population.
The fourth is choosing Named User Plus for a large server on the assumption that a small user base makes it cheap, when the minimum often makes Processor licensing cheaper and simpler. Avoiding these is a matter of always calculating the floor, counting every authorised user, and comparing the result to the Processor price before committing. The edition decision behind the 25 user figure is covered in the Enterprise Edition article.
Minimums on options and packs
The per processor minimum does not stop at the base database. Each separately licensed option and management pack licensed by Named User Plus carries its own minimum, calculated on the same processor count. A database licensed by Named User Plus with Partitioning and the Diagnostics and Tuning packs therefore has four separate minimums, one for the base and one for each option, all derived from the same core count.
This multiplies the effect of the floor. Where the actual user population sits below the minimum, the customer pays the minimum four times over, once for each layer, regardless of how few people use the system. The interaction means Named User Plus on a database with a rich option stack rarely saves money over Processor licensing, because every layer inherits the same floor. The option stack itself is covered in the options and packs article, and the combination should be modelled before the metric is chosen.
How hardware changes move the floor
Because the minimum derives from the processor count, every hardware change moves it. Adding cores raises the floor in proportion. Moving to a higher core factor processor family raises it further. A refresh undertaken purely for performance, with no change to the user population, can therefore increase the Named User Plus requirement simply by raising the processor count behind the minimum.
This is the hidden cost of the metric that catches estates which adopted Named User Plus for a stable user base and then refreshed hardware. The user count did not change, but the floor rose, and the licence requirement rose with it. The defensive practice is to re run the minimum calculation on any hardware change, treating it as a licensing event rather than a purely technical one, exactly as the core factor table article recommends for Processor licensing. The two metrics share the same hardware sensitivity through the processor count.
Common questions.
What is the Oracle Named User Plus minimum?
The Named User Plus minimum is the smallest number of user licences you must hold per processor, regardless of how few people actually use the database. For Oracle Database Enterprise Edition the minimum is 25 Named User Plus per processor, calculated on the licensable processor count after the core factor is applied.
How is the Named User Plus minimum calculated?
Take the physical cores, apply the core factor to get the processor count, then multiply by 25 for Enterprise Edition. A 32 core server at a 0.5 factor is 16 processors, so the minimum is 16 times 25, which is 400 Named User Plus licences even if only 50 people use the database.
When is Named User Plus cheaper than Processor?
Named User Plus is cheaper when the actual user count, after applying the minimum, is lower than the equivalent Processor licence cost. This favours databases with small, countable user populations on modest hardware. On large servers the per processor minimum can make NUP more expensive than Processor licensing.
Do all Oracle products have the same minimum?
No. The minimum varies by product and edition. Enterprise Edition Database is 25 Named User Plus per processor. Options and other products carry their own minimums, and Standard Edition 2 uses a different per server user minimum. The applicable minimum must be read from the licensing rules for each specific product.