Oracle Processor vs Named User Plus

The choice between Processor and Named User Plus is the most consequential pricing decision in the Oracle database stack, and it is made wrongly more often than any other. Both metrics describe the same database; they simply count different things. Getting the choice right can halve a licence bill, and getting it wrong is one of the most common avoidable overspends we see, second only to unlicensed options and packs. This article sets out exactly how each metric works and how to decide between them.

Which metric is cheaper for my database?

The honest answer is that it depends on a single ratio: how many users access the database relative to how many processor licences the hardware would require. Where the real user population is small and countable, Named User Plus is almost always cheaper. Where the population is large, unknown, or public facing, Processor wins because it does not care how many people log in. Every database in an estate should be modelled both ways, because the answer is not the same for all of them and the default chosen at purchase is frequently not the cheaper one.

This is not a one time decision either. A database that was cheaper under Named User Plus when it had forty users can flip to Processor being cheaper as the user count grows, and a hardware refresh that changes the core count can flip it back. The metric should be revisited whenever the user population or the hardware changes materially. The mechanics that sit underneath the Processor side of this calculation are covered in the core factor table article, and the full picture is in the database licensing pillar.

How the Processor metric is counted

Under the Processor metric you license the server, not the people. The count is physical cores multiplied by the core factor Oracle assigns to that processor type. A 32 core server on a processor with a 0.5 core factor requires 16 processor licences. The Processor metric is insensitive to usage: whether one person or one million people use the database, the licence requirement is the same, which is precisely why it is the only viable metric for systems whose user population cannot be enumerated.

The strength of Processor is its predictability. There is no user list to maintain, no audit dispute about who counts as a user, and no minimum to trip over. The weakness is that you pay for the full hardware capacity regardless of how lightly the database is used, which makes it expensive for small internal applications running on generously sized servers.

How Named User Plus is counted

Named User Plus licenses the people and the machines. A named user is any individual authorised to use the database, and, crucially, any non human operated device that accesses it. A batch job, an integration service account, a sensor, or a reporting tool that connects to the database is a named user under the definition. This is the single most misunderstood point in NUP counting: estates routinely count only employees and are then surprised when an audit adds every service account and device.

The strength of NUP is cost efficiency for small, well defined populations. The weakness is the counting burden and the risk of undercounting, plus the minimum that we turn to next, which sets a floor below which the saving disappears.

The 25 user per processor minimum

Named User Plus carries a contractual minimum for the database: at least 25 named users for every processor that would otherwise be required under the Processor metric. The minimum is not a suggestion; it is a floor that applies regardless of how few people actually use the system. This is the rule that decides most close calls.

In the first row, only sixty people use the database, but the minimum forces payment for two hundred named users. That is still likely cheaper than eight processor licences, but the saving is far smaller than the raw user count suggests. The minimum is the reason a database with very few users on a large server is sometimes cheaper under Processor after all: the minimum can climb above the real population and erode the NUP advantage.

Finding the break even point

The break even point is the user count at which Processor and Named User Plus cost the same. Above it, Processor is cheaper; below it, NUP is cheaper, subject to the minimum. Because the list price of a processor licence is a fixed multiple of a named user licence, the break even works out close to the NUP minimum itself for most configurations. The practical rule is straightforward.

1. Calculate the processor licences the hardware requires using the core factor.
2. Multiply by 25 to get the NUP minimum.
3. Count the actual named users, including every device and service account.
4. Use the higher of the actual count and the minimum as the NUP requirement, then compare the cost of that to the processor licence cost.

Where the actual user count sits well below the minimum, NUP is cheaper. Where it sits well above the break even, Processor is cheaper and removes the counting burden entirely. Where it sits close to the line, model both precisely, because a small change in either direction flips the answer.

Common counting mistakes

Three errors recur. The first is undercounting named users by omitting non human devices and service accounts, which understates the true NUP cost and produces an audit finding later. The second is forgetting the minimum, which leads teams to assume NUP is cheap for a tiny user base when the minimum has already made Processor competitive. The third is choosing one metric estate wide rather than per database, which leaves money on the table because the optimal metric differs across a portfolio.

A fourth, subtler error is failing to revisit the choice after a change. A virtualisation project, a hardware refresh, or a surge in integration accounts can each flip the cheaper metric, and an estate that locked its choice at purchase will drift into overpayment. Where a mismatch has already surfaced in an audit, the audit defence practice reconciles the counted population against the contract, and the database licensing service models the optimal metric across the whole estate.

The buyer side view

Processor versus Named User Plus is a maths problem, not a matter of opinion, and the maths is knowable in advance. The buyer side discipline is to model both metrics for every database, to count named users honestly including the machines, to apply the minimum, and to choose deliberately rather than by inertia. Done across an estate, this routinely surfaces databases that have been on the wrong metric for years. For the structured treatment of both metrics with worked examples, see the database licensing white paper, and to model your own estate, request a consultation.

The indirect access trap

One of the most expensive misreadings of Named User Plus concerns indirect access. The definition counts users who access the database, and Oracle interprets that to include people who reach the data through an intermediary application, a portal, or a reporting layer, even where they never see the database directly. A business intelligence tool that lets two thousand staff run reports against an Oracle database can, on Oracle's reading, create two thousand named users, even though those staff have no database credentials of their own.

This matters because organisations frequently size Named User Plus on the technical user accounts in the database, not on the human population reaching the data through applications. The gap between those two numbers is precisely where an audit finding lives. Where a large indirect population exists, the Processor metric often becomes the safer and cheaper choice, because it removes the argument about who counts entirely. The interaction with application licensing is explored further in the broader database licensing pillar, and the audit consequences are handled by the audit defence practice.

Multiplexing and the front end rule

Closely related to indirect access is multiplexing: the use of middleware, connection pools, or a front end application to funnel many users through a small number of database sessions. A common misconception is that multiplexing reduces the named user count because the database only ever sees a handful of pooled connections. Oracle's rule is the opposite. Named users are counted at the level of the individual person or device originating the request, not at the multiplexing layer, so a connection pool serving five thousand people requires five thousand named user licences, not one for each pooled session.

The front end rule is a frequent source of disputes precisely because the architecture is invisible at the database. An administrator looking at active sessions sees ten connections and assumes ten users; the audit counts the five thousand people behind them. The disciplined response is to map the full human and device population reaching the database through every application tier before choosing a metric, and where that population is large or hard to bound, to default to Processor.

Modelling a mixed estate

Real estates are not uniform, and the right answer is almost never a single metric applied everywhere. A typical portfolio contains small internal databases that are clearly cheaper under Named User Plus, large or public facing systems that must be Processor, and a band of middling systems where the answer turns on a careful count. Treating the estate as a portfolio rather than a single decision is where the largest savings are found, because it lets each database sit on its optimal metric.

The modelling exercise is mechanical once the inputs are gathered: for each database, establish the processor licences the hardware requires using the core factor, calculate the Named User Plus minimum, count the true human and device population including indirect and multiplexed users, and select the cheaper metric. Repeating this across the estate and re running it after any material change keeps the portfolio optimised. This is the standing discipline delivered by the database licensing service, and it pairs directly with the options discipline in the options and packs article.

Switching metrics and the renewal lock in

Choosing the right metric at purchase is only half the discipline; the other half is recognising that the metric is not always free to change later. Oracle licences are perpetual on a defined metric, and converting from Named User Plus to Processor, or the reverse, is a commercial negotiation rather than an administrative switch. An estate that started on the wrong metric can be carrying an avoidable cost that compounds with every support renewal, because support is calculated as a percentage of the licence fee originally paid.

This renewal mechanic is why metric errors are expensive in a way that is easy to miss. A database licensed on a suboptimal metric does not just cost more once; it costs more every year through inflated support, and that support base resists reduction because Oracle's repricing rules discourage shrinking a support stream. The buyer side opportunity is to identify these mispriced positions and to address them at a natural negotiation point, such as a renewal, a cloud move, or a ULA, where the metric can be reset as part of a larger deal rather than as an isolated request that Oracle has little incentive to grant.

The practical sequence is to model the optimal metric for every database, quantify the annual support cost of any mismatch, and time the correction to a moment of leverage. Trying to switch a single database's metric in isolation rarely succeeds; folding the correction into a renewal or a consolidation gives it commercial weight. This timing discipline connects the metric question to the broader negotiation strategy in the database pillar and the work of the database licensing service, and where a mismatch surfaces during an audit, to the audit defence practice.

For the middleware specific view, see Oracle middleware Named User Plus licensing and its per processor minimums.