What is the difference between Processor and Named User Plus?
The difference between Processor and Named User Plus is what each metric counts: Processor licences the hardware by counting cores adjusted by the core factor, while Named User Plus licences the people and devices that access the database. With Processor, cost follows the size of the server and is indifferent to how many people use it. With Named User Plus, cost follows the population of named users and any devices that reach the database, subject to a contractual minimum per processor. The two metrics answer the same question, how much do you owe, from opposite directions, and the right answer depends entirely on the shape of the deployment. The full mechanics are in the Oracle Database Licensing Guide.
How do Named User Plus minimums work?
Named User Plus minimums work by setting a floor of users per processor, so a database must be licensed to that minimum even when fewer people actually use it. This is the rule that turns a small user count into a larger licence requirement, and it is where audits frequently find an undercount. A team of ten using a database on a server whose minimum implies far more required users is short against the floor, not against the headcount. The minimum is contractual, so the only way to know your real Named User Plus requirement is to count the users and the devices and then test that figure against the per processor floor for each database.
For every Named User Plus database, count the actual named users and devices, then compare against the per processor minimum. Licence to whichever is higher, and never assume the headcount is the requirement when the floor may be above it.
When is Processor cheaper than Named User Plus?
Processor is cheaper than Named User Plus once the user population grows large or becomes hard to count, because the Processor cost stops scaling with people while the Named User Plus cost keeps climbing. There is a crossover point for every database, the user count at which the two metrics cost the same, and above it Processor wins while below it Named User Plus wins. Public facing systems, large internal user bases and any database reached by uncountable populations sit clearly on the Processor side. Small, fixed, well defined user groups that stay above the minimum but below the crossover sit on the Named User Plus side.
| Deployment shape | Usually cheaper | Why |
|---|---|---|
| Large or public user base | Processor | Cost stops scaling with people |
| Small fixed user group | Named User Plus | Below the crossover point |
| Uncountable users | Processor | Named User Plus cannot be counted reliably |
| Few users, big server | Check the minimum | The per processor floor may decide it |
Can you mix metrics across the estate?
Yes, you can and usually should mix metrics across the estate, choosing Processor for the databases with large or uncountable populations and Named User Plus for the small, fixed ones, because the cheapest licence is decided database by database, not estate wide. A single default metric applied everywhere almost always overpays somewhere. The work is to profile each database by its user shape and its server size, run the crossover calculation, and assign the metric that costs less while staying compliant. For a full numbers walk through, see the database licensing worked example and to remove unused capacity first, right sizing the database estate.
What is the next step?
The next step is to profile every database by user shape and server size, then assign the metric that costs less while keeping you compliant, including a check against the Named User Plus minimum on each one. The savings from getting the metric right across an estate are large, and the risk of getting it wrong is an audit undercount. Download the database licensing guide for the crossover method and the minimum check, and bring us your estate when you want the calculation done for you.
Download the Options and Packs Detection Guide and the database licensing framework for the metric crossover method and the minimum check. Get it from the white paper library, or read the full Oracle Database Licensing Guide.