Oracle Licensing: Named User Plus vs Processor — Which to Choose

The Two Oracle Licence Metrics: A Clear Definition

Every Oracle Database licence is counted on one of two primary metrics: Processor or Named User Plus (NUP). Oracle does not allow you to mix metrics on a single deployment — you must licence a database server, cluster, or shared environment entirely by Processor or entirely by NUP. The choice locks in your compliance approach and drives your cost structure for as long as you run that deployment.

Named User Plus (NUP) Defined

A Named User Plus licence authorises a specific individual, or a non-human device acting autonomously, to access Oracle software. Each NUP must be specifically named and authorised to use the software — not merely a potential user or a role definition. The word "plus" in Named User Plus means the licence includes the right for the user to access Oracle's technical support and receive software updates, not merely use the software.

Non-human operators (batch jobs, integration accounts, monitoring tools, system accounts) each count as one NUP if they access Oracle software directly. This is a common source of undercount — organisations that licence for their human users forget to count the service accounts and automated processes that also connect to Oracle databases.

Processor Licensing Defined

A Processor licence grants unlimited user access to Oracle software installed on a specific server or cluster. You pay based on the number of processor cores on the servers where Oracle runs, multiplied by Oracle's Core Factor for that hardware. For standard x86 Intel and AMD servers — which comprise the vast majority of enterprise Oracle deployments — the Core Factor is 0.5, meaning an eight-core server requires four Processor licences.

Processor licensing is metric-agnostic to users — once you've licensed the hardware, any number of people or systems can access Oracle. This makes it the default choice for deployments where the user population is large, external, or unpredictable.

The NUP Minimum Trap

The most common mistake organisations make with NUP licensing is underestimating the minimum licence requirements that Oracle mandates per processor core. Oracle does not allow an organisation to licence only the actual number of users if that number falls below the per-processor minimum.

For Oracle Database Enterprise Edition, the minimum is 25 Named User Plus licences per Processor (where Processor means the physical-core-count multiplied by the Core Factor). For a server with eight Intel cores (four Processor equivalents), the minimum NUP count is 100 — even if only 20 users access the database.

For Oracle Database Standard Edition 2, the minimum is 10 NUP licences per server (not per Processor), and SE2 is licensed per populated server socket rather than per core. A two-socket SE2 server requires a minimum of 20 NUP, regardless of actual user count.

Organisations that calculate NUP requirements based solely on actual user count, without applying the per-processor minimum, systematically undercalculate their NUP requirement and create audit exposure.

The Cost Crossover: When NUP Beats Processor

The pricing relationship between NUP and Processor licences is consistent: Oracle prices Processor licences at approximately 50 times the NUP licence price for Oracle Database Enterprise Edition. In 2026 terms, Oracle Database EE Processor list price is approximately $47,500 per Processor, while NUP list price is approximately $950 per user. Fifty NUP licences cost the same as one Processor licence at list price.

The practical crossover rule: if your authorised user count (including non-human operators, subject to the per-processor minimum) is less than 50 per Processor equivalent, NUP is likely more cost-effective. Above 50 users per Processor equivalent, Processor licensing becomes more economical.

This rule applies to list prices. At negotiated prices — which are significantly below list for both metrics in enterprise deals — the crossover point may shift. Independent benchmarking of your specific commercial terms is necessary to determine the actual crossover for your organisation.

A Worked Example

Scenario: Oracle Database Enterprise Edition on a server with eight Intel cores (4 Processor equivalents) accessed by 30 users and 5 service accounts (35 total NUP).

NUP requirement: The actual count of 35 NUP falls below the minimum of 100 NUP (25 × 4 Processor equivalents). The minimum applies, so 100 NUP are required. Cost at list price: 100 × $950 = $95,000.

Processor requirement: Four Processor licences. Cost at list price: 4 × $47,500 = $190,000.

Conclusion: NUP wins in this scenario because even after applying the minimum, 100 NUP ($95,000) is less than 4 Processor licences ($190,000). NUP remains cheaper as long as the total authorised user count (after applying minimums) is below approximately 200 for this server configuration.

Now change the scenario: 500 users access the same eight-core server. NUP requirement: 500 NUP (minimum of 100 applies but actual count of 500 is higher). Cost: 500 × $950 = $475,000. Processor cost: $190,000. Processor wins decisively.

Compliance Traps in NUP Licensing

NUP licensing creates specific compliance risks that Processor licensing does not.

Forgetting Non-Human Operators

Any process, system, or device that accesses Oracle software directly — even for a single automated task — requires a NUP licence. This includes monitoring agents, backup tools, ETL processes, middleware integration accounts, and any third-party application that queries Oracle directly. Many organisations licence only their human user count and overlook the automated access layer entirely. Oracle's LMS scripts identify all connection accounts, including system and service accounts, and Oracle counts them as requiring NUP licences.

User Count Growth

NUP licence counts must reflect current authorised users, not just initial deployment counts. As an organisation grows and adds users to Oracle-connected systems, the NUP count must increase proportionally. Failure to track and update NUP counts over time results in undercount at the next renewal or audit review. Annual internal audits of NUP authorisations against actual access accounts are essential for maintaining NUP compliance.

Indirect Access

Oracle's definition of NUP access extends to indirect access — users who access Oracle data through an intermediary application (ERP front-end, BI tool, custom application). If the application connects to Oracle on behalf of users without a separate multiplexing licence, each end user still requires a NUP or the deployment requires Processor licensing. The indirect access rules are frequently misunderstood and are a material source of Oracle audit exposure for organisations using third-party applications that sit in front of Oracle databases.

Compliance Traps in Processor Licensing

Processor licensing is simpler to manage than NUP but creates its own compliance risks.

Virtualisation and Soft Partitioning

The most significant Processor licence compliance risk is virtualisation. When Oracle runs on VMware, Hyper-V, or other soft partitioning technologies, Oracle requires all physical cores in the cluster — not just the vCPUs assigned to Oracle VMs — to be licensed. Customers who license only the vCPUs assigned to their Oracle VM on a large Hyper-V cluster are typically underlic ensed by 200 to 600 percent of their actual requirement. See Oracle Licensing on Hyper-V for full details.

Unlicensed Database Options

Processor licences entitle you to run Oracle Database — not Oracle Database plus all its optional features. Options such as Real Application Clusters, Partitioning, Advanced Security (TDE), Active Data Guard, and Diagnostics Pack are separately licensed. If these are enabled in the database, additional Processor-metric licences for each option are required. Oracle's LMS scripts automatically detect enabled options.

Overlooked Installations

Every server where Oracle Database is installed — including development, test, staging, and DR environments — requires Processor licences unless a separate provision (such as a developer licence for development use only) applies. Development and test installations are a common source of unlicensed exposure, particularly in larger IT organisations where servers are provisioned without licence review.

The Decision Framework

Choose Named User Plus when: your authorised user population (including all non-human operators) is small and stable; you can definitively identify and count every individual and system authorised to access Oracle; user count after applying the per-processor minimum is below approximately 50 per Processor equivalent; and the deployment is internal-facing with controlled access.

Choose Processor when: the user population is large, external, or unpredictable; accurately counting all authorised NUPs would be impractical; the deployment serves internet-facing applications; user count exceeds 50 per Processor equivalent; or you want the simplest possible compliance management approach.

The support fee consideration applies equally to both metrics. Oracle's 8% annual support fee escalation applies regardless of whether you licence by NUP or Processor. The metric choice affects the licence base; the 8% escalation applies to whatever that base is. Choosing the right metric at deployment is therefore doubly important — a higher licence base means a higher annual support cost escalating at 8% per year into the future.

Switching Between Metrics

Oracle does not permit free switching between licence metrics. If you want to change from NUP to Processor or vice versa, this is treated as a licence exchange — you trade your existing NUP licences for Processor licences (or vice versa) at Oracle's current exchange rates, which are typically at list price and therefore unfavourable compared to what you originally paid. The best time to choose the right metric is at initial deployment, informed by an independent cost analysis across both options.

Metric changes are sometimes possible in the context of a ULA certification, ULA renewal, or other major commercial negotiation, where Oracle may agree to a metric conversion as part of a broader commercial resolution. This is another reason why major Oracle commercial events should be managed with independent advisory support.