Named User Plus or Processor: The Oracle Metric Decision

Oracle sells the same database two ways, per named user and per processor, and the choice between them can move the licence bill by a factor of ten on identical hardware. The decision turns on two numbers.

Prepared by Redress Compliance · July 2026 · Oracle licensing advisory. Representative Oracle estate scenario (benchmark scenario, not a quote). List prices per the Oracle Technology Global Price List.

Oracle offers Enterprise Edition on two counting metrics, and they measure completely different things. Named User Plus counts the individuals and devices authorised to use the database. Processor counts the hardware the database runs on, after the core factor. You license on one or the other, not both, and the right choice is a function of how many people use the system relative to how much hardware it sits on.

The gap between the two can be enormous. A database on a two processor footprint serving 30 named users costs 30 × $950, or $28,500, on the NUP metric. The same database on the Processor metric costs 2 × $47,500, or $95,000. Pick the wrong metric and you more than triple the bill. Reverse the population — the same two processors serving 5,000 users — and NUP would cost $4.75M against $95,000 on Processor. The metric decision is the single largest lever in Oracle Database licensing, ahead of discount.

Named User Plus looks cheap for a small team until the minimum bites. Enterprise Edition requires a minimum of 25 Named User Plus per processor. The count you license is the higher of the actual authorised users or 25 times the licensable processor count. A two processor database therefore carries a floor of 50 NUP, or $47,500, whether it serves 50 users or five.

Two rules make the minimum sharper than it first appears. First, the processor count in the minimum is the licensable count after the core factor, so a 16 core x86 server counts as 8 processors and floors NUP at 200 users. Second, Named User Plus counts non-human operated devices as well as people, so batch feeds, sensors, and service accounts can push the real count above the human headcount.

• Count every authorised user and device. The metric is authorised, not active. A user provisioned but idle still counts, and a device that accesses the database counts even with no human at it.
• Apply the minimum per processor. The floor is 25 × the licensable processor count, and you pay the higher of that or the real population.
• Watch multiplexing. Pooling users behind a middle tier does not reduce the count. Oracle counts the users at the front of the multiplexer, not the connections at the back.

A practical consequence is that the metric governing each module is written into the contract and does not float year to year, so a licensing decision taken at purchase governs cost for the life of the deployment. Before any renewal, reconcile every module to its contracted metric and its licensed quantity, because an estate that has never verified which metric applies where cannot know whether it is over-licensed on Processor or exposed on Named User Plus. That reconciliation is cheap to do and expensive to skip.

The decision reduces to one line of arithmetic. Divide the Processor price by the NUP price: $47,500 ÷ $950 = 50. Above 50 users per processor, the Processor metric is cheaper; below 50, Named User Plus is cheaper, floored at the 25 minimum. The table works a two processor Enterprise Edition database across three populations.

The same two processor database tells the whole story when the population moves. At 30 authorised users the Named User Plus metric costs a fraction of the Processor licence; scale the same database to 300 users and the relationship inverts entirely. The Processor line never moves, because it is set by the hardware, while the Named User Plus line rises with every seat.

The break even only matters when you are free to choose, and often you are not. Named User Plus requires that every user be identifiable and countable, because the metric licenses authorised individuals and devices. Where the population cannot be counted, Oracle requires the Processor metric.

• Public and internet-facing systems. A website, a customer portal, or an open API has an unbounded user base that cannot be enumerated, so it must be licensed on Processor.
• Uncounted device access. Where sensors, meters, or automated feeds access the database in numbers you cannot fix, the device count defeats NUP and Processor is required.
• Mixed internal and external. A system that serves both named staff and anonymous external users cannot split the metric; the external population forces Processor for the whole database.

The buyer side discipline is to classify each database by countability first. Internal, bounded populations are candidates for the NUP break even; anything public defaults to Processor before the arithmetic even runs.

Hybrid systems deserve particular care. A database that begins life internal and later exposes a customer or partner portal silently changes its counting basis, because the new external population cannot be enumerated. The review point is any change that widens who can reach the data, not only the initial deployment, so a system re-scoped for external access should be re-tested for the Processor requirement before it goes live, not after an audit discovers the exposure.

Both metrics rest on the processor count, and that count is not the raw core count. On premises, licensable processors equal physical cores multiplied by Oracle's core factor, which is 0.5 for the x86 hardware most estates run. A 16 core x86 server is 8 licensable processors. That 8 drives the Processor licence directly, and it drives the NUP minimum at 25 per processor, or 200 users.

Because a single number feeds both metrics, a core factor error doubles in effect. Count the cores raw, and you over-license the Processor metric and over-floor the NUP minimum at once. The mechanics of the core factor, and where it applies and does not, are worked in full in our companion paper, The Oracle Core Factor Table.

The interaction is worth stating plainly, because it doubles the effect of an error. A processor count taken before the core factor overstates the Processor licence and simultaneously inflates the Named User Plus minimum, so a single miscount can push a buyer toward the wrong metric and overpay on the one they choose. Counting the processors correctly is the precondition for the metric decision, not a separate exercise that can follow it.

Standard Edition Two does not play by the same rules, and assuming it does is a common error. SE2 is licensed per socket, not per core with a factor, and its Named User Plus minimum is 10 per server, not 25 per processor. For a small, bounded workload that fits the SE2 socket and vCPU limits, the SE2 NUP minimum of 10 users per server is dramatically lower than the Enterprise Edition floor, which is often the cheaper answer than an Enterprise Edition database on either metric.

The two editions are different licensing worlds, not two prices for the same thing. Standard Edition Two removes the core factor, the per-processor Enterprise pricing, and the 25-per-processor floor in a single move, replacing them with a per-socket basis and a 10-per-server minimum. The first question on any modest workload is therefore not which Enterprise metric to choose, but whether the workload fits Standard Edition Two at all.

The lever is to test whether the workload fits SE2 before optimising the Enterprise Edition metric. A workload that can live on SE2 sidesteps the core factor, the 25 NUP floor, and the entire options question in one move.

The common advice is that Named User Plus is always the cheaper choice for a small team. We disagree, and the minimum is why.

For a genuinely small, bounded, internal population NUP can win, but the 25 per processor floor removes the saving faster than buyers expect, and the core factor sets that floor higher than the raw core count suggests. In the estates we reviewed, NUP was frequently chosen for a small team on a large server, where the 25 per processor minimum priced the licence above the Processor metric the buyer was trying to avoid. The reverse error also recurs: Processor chosen for a bounded 30 user internal system that NUP would have licensed for a third of the cost.

The buyer side move is to run the break even per database against the real, counted population and the core-factored processor count, and to re-test it when the population or the hardware changes. The metric is not set once; it is the outcome of a calculation that shifts with the workload.

The reverse error is just as common and just as expensive. Processor is chosen for a bounded, internal system of a few dozen users on the reasoning that it is simpler, when Named User Plus would have licensed the same database for a third of the cost. Neither metric is inherently cheaper or safer; each is correct for a specific ratio of users to processors, and the only way to know which applies is to run the number for the actual estate rather than to standardise on one metric across the whole of it.

Five metric findings recur in an Oracle review, and each has a buyer side answer set before an audit rather than after.

The metric decision is the largest number in Oracle Database licensing. It is a calculation, not a policy, and the buyer who runs it per database controls a factor-of-ten swing.

The metric decision runs on a short, repeatable sequence, and it is worth running on every database at every renewal because the answer moves as the population and the hardware change.