Oracle pricing metrics. The CIO playbook.

Oracle pricing is set by the metric before it is set by the discount. The Oracle Technology price list publishes a list price per metric, and the wrong metric on a contract overcharges regardless of how good the discount looks.

Four metrics govern most Oracle deals: Named User Plus, processor, the employee metric, and application user metrics. Each has a minimum and a counting rule that decides the real bill.

This playbook sets each metric, the minimum that catches buyers, and the buyer side move that holds the count down at renewal.

How does the Oracle Named User Plus metric work?

Named User Plus counts every individual authorized to use the program, plus every device that does so automatically. It is the metric for systems with a known, countable user population.

The catch is the minimum. Oracle sets a Named User Plus minimum per processor, commonly 25 for Enterprise Edition. On a low user, high core system the minimum, not the headcount, sets the bill.

The minimum that catches buyers

• Count authorized users and any devices that operate the program.
• Apply the per processor minimum, commonly 25 for Enterprise Edition.
• License the higher of the actual count and the minimum.

When does the Oracle processor metric win?

The processor metric licenses by physical cores multiplied by the core factor. It does not count users, which makes it the metric for public facing, batch, or high user systems where counting users is impractical.

White Paper · Oracle

The Oracle Buyer Side Framework

The moves we use across Oracle Database, Java and ULA estates. Read it free.

Read the white paper

The core factor link

The processor count flows from the Oracle Processor Core Factor Table. Get the factor right before comparing the processor metric against Named User Plus. Read the related Oracle core factor guide.

How does the Oracle employee metric work?

The employee metric counts total employees, contractors, and agents, not software users. Oracle moved the Java SE Universal Subscription to this metric in 2023, which expanded the count to the whole organization.

The buyer side error is counting Java users rather than total employees. The metric counts everyone, so the exposure is far larger than the user base suggests.

• Count the whole organization, including contractors and agents.
• Do not count Java users, the metric ignores actual usage.
• Right size first, then anchor against an OpenJDK alternative.

How do Oracle application user metrics work?

The applications estate uses module specific metrics. E Business Suite, PeopleSoft, and Fusion each count differently, by application user, employee record, or enterprise metric depending on the module.

The move is to align the metric to the actual user pattern per module and true down dormant licenses at renewal. Read the related Oracle Fusion Cloud applications guide.

How Redress engages on metrics

Redress runs the metric comparison and the conversion analysis inside the Benchmark Program and defends the position through Vendor Shield. Read the Oracle services practice and the Oracle knowledge hub.

Where the common advice on Oracle metrics is wrong

The standard advice is to pick Named User Plus whenever you can count your users, because it looks cheaper than processor licensing. We disagree. Across the 40 to 50 metric reviews we ran in 2024 and 2025, the Named User Plus minimum per processor forced a 25 to 40 percent higher count than the actual population on low user, high core systems, and processor licensing was the cheaper path in those cases. The cheaper metric is workload specific, not universal. The buyer side move is to model both metrics against the real user count and core count per system, then license each system on its lower cost metric rather than applying one rule across the estate.

What to do next

1. Inventory every metric. List which metric governs each Oracle program in the estate.
2. Model both metrics. Compare Named User Plus and processor cost per system.
3. Apply the minimum. Check the Named User Plus per processor minimum on low user systems.
4. Count Java by employee. Use total employees, not users, for the Java SE metric.
5. Align application metrics. Match each module metric to its actual user pattern.
6. Plan the conversion. Schedule any metric switch for the renewal window.
7. True down dormant licenses. Remove unused counts before the next order.

Frequently asked questions

What is the Oracle Named User Plus metric?

Named User Plus counts every individual authorized to use the program plus every device that operates it automatically, subject to a per processor minimum. On a low user, high core system the minimum, not the headcount, sets the bill.

What is the Named User Plus minimum per processor?

Oracle sets a Named User Plus minimum per processor, commonly 25 for Enterprise Edition. You license the higher of the actual authorized count and the minimum, so the minimum can force a higher count than the real population.

When is the Oracle processor metric cheaper than Named User Plus?

The processor metric is cheaper on public facing, batch, or high core systems where the user count is large, unbounded, or impractical to count, and where the Named User Plus minimum would exceed the processor cost.

How does the Oracle employee metric work?

The employee metric counts total employees, contractors, and agents, not software users. Oracle moved the Java SE Universal Subscription to this metric in 2023, which expands the count to the whole organization.

Is the Oracle Java SE metric counted by users?

No. The Java SE Universal Subscription is counted by total employees, including contractors and agents, regardless of how many people use Java. Counting users instead understates the exposure.

How do Oracle application user metrics differ?

E Business Suite, PeopleSoft, and Fusion use module specific metrics that count by application user, employee record, or enterprise metric depending on the module. Align each metric to the actual user pattern.

Can I switch Oracle metrics at renewal?

Yes, and metric conversion is a major lever. Where a system sits on the costlier metric, model the switch and schedule it for the renewal window. Some conversions require Oracle approval.

Which metric should I use across the estate?

There is no single right metric. Model Named User Plus and processor cost per system against the real user and core counts, then license each system on its lower cost metric rather than applying one rule everywhere.