Oracle's Named User Plus (NUP) metric looks like a user-based license — you pay per named user who accesses the database, middleware, or application. What many enterprise buyers discover too late is that Oracle imposes a minimum NUP count that has nothing to do with your actual user population. The 25 NUP per processor minimum is Oracle's mechanism for ensuring that NUP licensing never produces a result cheaper than processor licensing on low-user, high-capacity systems. Understanding when this minimum applies, how it interacts with the Core Factor Table, and how to optimize your NUP position at contract renewal is the difference between a defensible license position and a floor-driven cost trap.
Oracle's Named User Plus (NUP) metric licenses Oracle software for use by a specific, identified individual. Unlike the Processor metric — which licenses based on the physical processor capacity where Oracle software runs, regardless of how many people use it — NUP ties the license obligation to the count of named users authorized to access the Oracle software. A named user is a person who has been authorized to use a specific Oracle product, regardless of whether they use it concurrently, frequently, or at all.
The NUP metric appears straightforward: count the users, buy that many licenses, pay 22% annual support on the license value. In practice, Oracle's NUP rules introduce three complications that routinely create compliance exposure for enterprises. First, the definition of a "named user" is broader than most buyers initially assume — it includes contractors, temporary staff, and users of applications that indirectly access Oracle Database. Second, for Oracle Database and many middleware products, Oracle imposes a minimum NUP count per processor that may exceed your actual user count. Third, the NUP metric interacts with Oracle's Core Factor Table in ways that make the minimum calculation non-intuitive for multi-socket servers.
Understanding these three complications — and specifically the NUP minimum — is essential for any enterprise evaluating whether the NUP metric or Processor metric produces the lower cost for their specific deployment, and for building a defensible ELP for Oracle audit defense.
Oracle's Database licensing policy states that for Oracle Database Enterprise Edition licenced on the NUP metric, the minimum number of Named User Plus licenses required is 25 per Processor. The "Processor" in this context refers to the Oracle Processor metric unit — which is not the same as a physical CPU socket or core count. The Oracle Processor metric is defined by applying the Core Factor Table to the physical processor architecture of the server where Oracle Database runs.
The 25 NUP per Processor minimum exists because Oracle wants to ensure that NUP licensing cannot produce a result dramatically lower than Processor licensing for the same deployment. Without a minimum, a powerful server running Oracle Database for 3 users would require only 3 NUP licenses — a tiny fraction of the cost of licensing the same server on the Processor metric. The minimum creates a floor that aligns the two metrics for low-user scenarios.
The practical application: a server with 2 physical sockets, each containing an Intel Xeon processor (Core Factor 0.5), hosts Oracle Database Enterprise Edition. The processor count for Oracle licensing purposes is 2 sockets × 12 cores × 0.5 Core Factor = 12 Oracle Processor units. The NUP minimum is 25 NUPs per Oracle Processor unit × 12 Oracle Processor units = 300 NUPs minimum. If your actual named user count is 150, the minimum still requires 300 NUPs. If your actual named user count is 400, the actual count governs — you need 400 NUPs, not 300.
The minimum applies regardless of actual usage. Oracle's NUP minimum is not based on how many users actually log into the database. It applies to the number of users authorized to access the database — and the minimum floor ensures that even an Oracle Database instance with 5 actual users requires 25 NUPs per Oracle Processor unit of capacity. Many enterprises with low user counts discover at audit that NUP was not the cheaper option they assumed.
Oracle Database Standard Edition 2 (SE2) has a different NUP minimum — the license terms vary by product version and edition. Enterprises should verify the specific NUP minimum in their Oracle license definitions and the current Oracle Technology Global Price List for their products. The 25 NUP per Processor minimum applies most commonly to Oracle Database Enterprise Edition and is the most significant in financial terms due to EE's higher per-NUP list price.
The interaction between Oracle's Core Factor Table and the NUP minimum creates counterintuitive results that enterprise buyers frequently misunderstand, sometimes in their favor and sometimes not.
Oracle's Core Factor Table assigns a multiplier to each processor architecture that reduces (or occasionally increases) the number of license units required per physical core. Intel Xeon and AMD EPYC processors carry a Core Factor of 0.5 — each physical core counts as 0.5 Oracle Processor units. IBM POWER10 processors carry a Core Factor of 1.0 — each physical core counts as 1 Oracle Processor unit. SPARC processors vary by generation. The total Oracle Processor units for a server is: physical sockets × cores per socket × Core Factor.
The NUP minimum applies to Oracle Processor units (after Core Factor reduction), not to raw physical cores. This is significant for high-core-count Intel/AMD servers. A server with 4 sockets × 32 cores × 0.5 Core Factor = 64 Oracle Processor units. At 25 NUPs per Oracle Processor unit, the NUP minimum is 1,600 NUPs. At Oracle Database EE NUP list pricing of approximately $380 per NUP per year (including 22% support), 1,600 NUPs costs roughly $608,000 annually. The alternative — 64 Oracle Processor units at EE list price of $47,500 with 22% support — costs $60,800 annually. This example illustrates why the Processor metric is almost always the correct choice for large servers.
Our License Optimization team performs forensic metric comparison analyses, applying the Core Factor Table correctly to your specific server configuration to determine the optimal metric for your Oracle deployment profile.
Oracle's definition of a Named User Plus is a person who has been authorized to use the Oracle program (product). The key word is "authorized" — not "active user," not "logged in last 30 days," not "accessing the database directly." Oracle's LMS audit process counts authorized users, and the definition of authorization is interpreted broadly.
Any employee, contractor, temporary worker, or other individual who has been granted access credentials to an Oracle Database — or to an application that accesses Oracle Database — is a Named User Plus under Oracle's definition. Contractors are full NUP users at Oracle's list price; there is no discounted rate for contingent workers, temporary staff, or outsourced service delivery personnel who access Oracle software.
Machine-to-machine connections — application service accounts that connect to Oracle Database to read or write data — are also subject to NUP licensing consideration. Oracle's policy is that a Named User Plus license is required for each person (or device, for the Device metric available for certain products) that is authorized to use the program. For service accounts that represent automated application connections rather than individual humans, Oracle's interpretation has varied by audit team. Challenging service account NUP counting requires detailed contract review and is an area where our audit defense team frequently achieves meaningful reductions in Oracle's claimed NUP count.
Indirect use — users who access Oracle Database through an intermediary application — creates NUP exposure for users who never directly interact with the database. If 500 employees use a web application that queries Oracle Database, Oracle's position is that those 500 employees are Named Users for Oracle Database purposes, even if the only Oracle interface is a service account connection at the application tier. This indirect use NUP obligation can dramatically exceed the direct user count and is one of the most contested areas in Oracle license audits.
The fundamental NUP vs Processor metric decision is a straightforward breakeven calculation: at what user count does NUP become more expensive than Processor licensing for the same deployment?
The breakeven formula for Oracle Database Enterprise Edition: (Oracle Processor units × $47,500) vs (max(actual NUP count, Oracle Processor units × 25) × $380). If your actual named user count exceeds 125 per Oracle Processor unit (the point where NUP list price exceeds Processor list price: 125 NUPs × $380 = $47,500), NUP is more expensive than Processor for that server.
| Scenario | Oracle Processor Units | Actual Users | NUP Required | NUP Cost (annual) | Processor Cost (annual) | Better Metric |
|---|---|---|---|---|---|---|
| Small server, few users | 4 | 30 | 100 (minimum) | $38,000 | $22,800 | Processor |
| Small server, moderate users | 4 | 80 | 100 (minimum) | $38,000 | $22,800 | Processor |
| Large server, low users | 32 | 50 | 800 (minimum) | $304,000 | $182,400 | Processor |
| Small server, high users | 4 | 600 | 600 (actual) | $228,000 | $22,800 | Processor |
| Tiny server, very few users | 1 | 10 | 25 (minimum) | $9,500 | $5,700 | Processor |
This table illustrates a consistent pattern: for Oracle Database Enterprise Edition deployed on x86 infrastructure with the 0.5 Core Factor applied, the Processor metric produces a lower cost than the NUP metric in virtually all realistic enterprise deployment scenarios. The NUP metric can be advantageous for Oracle Database Standard Edition 2 in specific configurations, or for Oracle middleware and application products where the NUP minimum and pricing structures differ from Database EE. Each product and deployment configuration requires individual analysis.
The 25 NUP per Processor minimum applies specifically to Oracle Database Enterprise Edition. Other Oracle products have their own NUP minimum structures, which vary by product and are specified in Oracle's Technology Global Price List and the product-specific license definitions.
Oracle WebLogic Server licenced on the NUP metric has NUP minimums specified in the WebLogic Server license terms. Oracle's middleware products — SOA Suite, Integration Cloud, Coherence — have license definitions that specify applicable metrics and minimums. Oracle E-Business Suite, PeopleSoft, JD Edwards, and Siebel applications are typically licenced on an Application User metric rather than NUP for most modules, but some modules or integration components may have NUP license requirements with specified minimums.
For Oracle Applications users, the relevant license metric is often "Application User" — a user who has been set up in Oracle's application user table and is authorized to use the application. Application User licensing for Oracle EBS, PeopleSoft, and JD Edwards has its own minimum rules and counting methodology. The principles are similar to NUP — authorized access rather than active use determines the count — but the specific minimums and metric definitions differ. Our Database Licensing Guide and the product-specific guides in our resource library provide detailed minimum rules by product.
Oracle's LMS scripts deployed during an Oracle license audit query Oracle Database's DBA_USERS view to enumerate database user accounts. The LMS audit report typically shows the total number of database user accounts as the basis for the NUP count. Oracle's auditors then apply the following logic: count of authorized users = max(DBA_USERS count, 25 × Oracle Processor units). The NUP license obligation is the larger of the two.
There are several areas where enterprises can challenge Oracle's LMS-generated NUP count. Application schemas — database user accounts created for application connectivity rather than individual users — are frequently counted as Named Users by Oracle's LMS scripts. If you can demonstrate that these accounts represent service-to-service connections rather than individual human users, this can reduce the NUP count significantly. Locked or expired user accounts — accounts that have not been used and cannot be used without administrative intervention — may be challengeable as not constituting "authorized users." Default Oracle schema accounts (SYS, SYSTEM, DBSNMP, OUTLN) should be excluded from the NUP count.
These challenges require forensic analysis of the DBA_USERS output, detailed application architecture documentation, and negotiation skill in the LMS audit process. For a pharmaceutical client whose LMS audit identified 840 Named Users based on DBA_USERS count (versus 280 individual humans who actually accessed the database), our audit defense team challenged the inclusion of 560 application schema and service accounts, reducing the back-license claim from $1.9M to $640K. See our pharmaceutical case study for related audit defense outcomes.
Oracle NUP optimization requires both a technical and contractual approach. The technical approach focuses on building the most accurate and defensible NUP count possible. The contractual approach focuses on using that accurate count to right-size your NUP entitlements at contract renewal.
Build a clean DBA_USERS inventory. The starting point for NUP optimization is a clean database user account inventory that distinguishes individual humans from application schemas, service accounts, and system accounts. For each Oracle Database instance, categorise accounts: (1) named individual users who access the database for business purposes; (2) application service accounts that connect on behalf of groups of application users; (3) DBA and system accounts; (4) locked, expired, or decommissioned accounts. Category 1 accounts are unambiguous Named Users. Categories 2–4 are areas where Oracle's LMS count may be challenged or negotiated.
Apply the NUP minimum calculation correctly. Calculate your Oracle Processor unit count accurately, applying the Core Factor Table for your specific server architecture. This is the floor for your NUP obligation — even if category 1 accounts are fewer than 25 per Processor unit, the minimum determines your obligation. If the minimum exceeds your actual user count significantly, this is a strong signal that the Processor metric is more appropriate for your deployment.
Right-size at contract renewal. If you hold NUP entitlements in excess of your current obligation (accounting for the minimum), the excess is shelfware. Oracle Oracle agreement renewal is the window to right-size your NUP entitlements downward — removing excess NUPs from the support schedule and eliminating the corresponding 22% annual support cost. Oracle will resist this; you need documented evidence of your NUP obligation (the clean user inventory and minimum calculation) to support the negotiation.
Consider metric switching. For Oracle Database Enterprise Edition on x86 servers with significant core counts, switching from NUP to Processor licensing at contract renewal frequently reduces cost. The Processor metric eliminates the NUP minimum dynamic entirely and produces a more predictable cost trajectory as your user base grows. Our Contract Negotiation service supports metric switch discussions at Oracle Oracle agreement renewals.
Weekly briefings on Oracle license counting rules, NUP optimization, and audit risk management. Read by ITAM teams, legal, and procurement professionals at enterprise Oracle customers.
Our license optimization specialists analyze your Oracle Database deployment, apply the Core Factor Table correctly, and determine whether NUP or Processor licensing — and what quantity — represents your optimal position. Independent, buyer-side, not affiliated with Oracle.