Why Oracle Imposes NUP Minimums
Oracle's Named User Plus licensing allows customers to licence Oracle software based on the number of individuals and non-human devices authorised to access the software. In theory, a small user population on powerful hardware could allow an organisation to acquire far fewer licences than the hardware's processor capacity would warrant under Oracle's Processor licensing metric. Oracle's NUP minimum rules prevent this outcome by tying the minimum acceptable NUP count to the processor capacity of the underlying hardware.
The NUP minimum rules effectively establish a floor: you must always licence at least as many NUP users as the processor-based minimum calculation requires, even if your actual user count is lower. This makes NUP licensing economically advantageous only for environments where the actual user count is close to or above the minimum — and it makes NUP an inappropriate metric for large-server environments with small user populations.
Understanding the minimum calculation is essential for two reasons. First, organisations that licence by NUP need to confirm they are not below the minimum — an audit finding of under-licensing below the NUP minimum carries the same financial consequences as any other under-licensing finding. Second, organisations evaluating whether to use NUP or Processor licensing need the minimum calculation to determine at which user population level NUP becomes cheaper than Processor licensing.
The Two-Step Minimum Calculation Formula
Oracle's NUP minimum calculation requires two sequential steps. The first determines how many Processor licences the hardware would require under the Processor licensing metric. The second applies the per-product NUP minimum multiplier to that processor count.
Required NUP = MAX(Actual Authorised Users, NUP Minimum)
The final NUP licence count you must hold is whichever is greater: your actual count of authorised users and non-human devices, or the calculated NUP minimum. You cannot hold fewer than the NUP minimum regardless of how few users actually access the system.
The Oracle Core Factor Table
Oracle's Core Factor Table assigns a multiplier to each processor type and model. The core factor adjusts for the different performance characteristics of various processor architectures — a high-throughput SPARC core is treated differently from an x86 core, for example. The table is maintained by Oracle and updated periodically as new processor models enter the market.
The most common core factors for enterprise hardware in 2026 are:
- Intel x86 and AMD x86 processors (all modern models): 0.5 — meaning each physical core counts as half a processor licence
- IBM POWER9 and POWER10: 1.0 — each core counts as one processor licence
- Oracle SPARC (T-Series, M-Series): varies from 0.25 to 1.0 depending on specific model
- Sun UltraSPARC T1 (1.0 or 1.2 GHz): 0.25
For the vast majority of enterprise Oracle deployments on modern x86 hardware (Intel or AMD), the core factor is 0.5. This means a server with 32 physical cores requires 32 × 0.5 = 16 Processor licences under the Processor metric. The 2025 update to Oracle's Core Factor Table added several new Intel Xeon 69xxP, 67xxE, 67xxP, 65xxP, and E-24xx processor families at the standard 0.5 core factor.
It is critical to use Oracle's published Core Factor Table for your specific processor model. Do not assume that all processors carry the same factor — IBM POWER systems carry a 1.0 factor which doubles the licence requirement versus equivalent x86 deployments, and some older SPARC systems carry different factors that require verification against the Oracle-published table.
Worked Example 1: Oracle Database Enterprise Edition on Intel Server
Consider a server with two Intel Xeon Gold processors, each with 20 physical cores, running Oracle Database Enterprise Edition.
Core Factor: 0.5 (Intel x86)
Processor Licences: 40 × 0.5 = 20 Processor licences
NUP Minimum: 20 × 25 = 500 Named User Plus licences
Required NUP: MAX(Actual Users, 500)
In this example, if your actual authorised user count is 350, you still must hold 500 NUP licences — the minimum. If your actual user count is 600, you must hold 600 NUP licences — the actual count exceeds the minimum. Only when actual users exceed the minimum does the minimum cease to constrain your licence count.
Compare this to the Processor licensing cost: 20 Processor licences at Oracle's list price for Database Enterprise Edition ($47,500 per Processor licence) = $950,000 in licence fees plus 22% annual support. The NUP calculation at 500 users ($950 per NUP at list) = $475,000 plus support. In this example, NUP is cheaper than Processor licensing — but only because the actual user population (350) is well below the minimum threshold. If users grow to 800, NUP becomes more expensive unless negotiated pricing adjusts.
Need a NUP vs Processor calculation for your environment?
Our Oracle specialists build accurate licence models for your specific hardware and user profile.Worked Example 2: Oracle Database SE2 on a Two-Socket Server
Standard Edition 2 uses a different minimum structure. Instead of 25 NUP per Processor licence, SE2 requires a minimum of 10 NUP per server. This reflects SE2's server-based licensing model, where the licence covers the physical server regardless of socket count.
One physical server: 10 NUP minimum
Required NUP: MAX(Actual Users, 10)
For SE2, the per-server minimum is straightforward — 10 NUP per server regardless of core count or socket configuration. A two-socket SE2 server with 16 cores per socket still only requires 10 NUP minimum, provided SE2's two-socket limit is respected. If your actual users number 8, you must hold 10 NUP; if your actual users number 25, you must hold 25 NUP.
It is important to note that Standard Edition 2 has a hard limit of 2 populated sockets per server. If you need more than two sockets, you must use Enterprise Edition, which changes the minimum calculation entirely as shown in Example 1.
Worked Example 3: IBM POWER Server with Oracle Database EE
For organisations running Oracle on IBM POWER hardware, the 1.0 core factor doubles the processor licence count compared to x86, which significantly affects the NUP minimum.
Core Factor: 1.0 (IBM POWER9/10)
Processor Licences: 16 × 1.0 = 16 Processor licences
NUP Minimum (EE): 16 × 25 = 400 Named User Plus licences
A single 16-core IBM POWER server running Oracle Database Enterprise Edition has the same NUP minimum (400) as a 32-core Intel server (32 × 0.5 = 16 processor licences × 25 = 400). This illustrates why the Core Factor Table must be applied carefully — hardware architecture directly determines the NUP minimum, and IBM POWER systems carry a materially higher NUP minimum than equivalent x86 configurations.
NUP Minimums for Oracle Fusion Middleware
Most Oracle Fusion Middleware products — WebLogic Server, SOA Suite, WebCenter, Oracle Business Intelligence Enterprise Edition, Oracle Identity Management — apply a 10 NUP per Processor minimum rather than the 25 per Processor used for Database Enterprise Edition.
NUP Minimum Rate: 10 per Processor licence
NUP Minimum: Processor Licences × 10
Using the same Intel server from Example 1 (20 Processor licences), the Middleware NUP minimum would be 20 × 10 = 200 NUP licences — significantly lower than the 500 minimum for Database EE. This reflects Oracle's commercial intent: middleware products are typically accessed by broader populations than databases, so the lower per-processor minimum makes NUP licensing more competitive for middleware.
Applying the Minimum to Mixed Environments
Enterprises running multiple Oracle products on the same server must apply the NUP minimum for each product separately. The NUP minimum for Oracle Database Enterprise Edition (25 per processor) and Oracle WebLogic Server (10 per processor) are calculated independently, and the user counts for each product are tracked separately.
A user who accesses both Oracle Database and Oracle WebLogic on the same server requires NUP licences for both products. However, the licence counts for each product are maintained independently — the Database NUP count and the WebLogic NUP count are separate quantities subject to their respective per-processor minimums.
When Oracle's LMS (Licence Management Services) team conducts an audit, they apply the minimum calculation to each deployed Oracle product separately. An organisation with 15 Oracle products deployed faces 15 separate minimum calculations — any shortfall in any product is an audit finding subject to back licence fees and support charges.
How NUP Minimums Affect Audit Findings and Support Costs
An audit finding that an organisation holds fewer NUP licences than the minimum calculation requires is treated identically to any other under-licensing finding. Oracle will demand payment for the difference between the minimum NUP count and the licences held, calculated at Oracle's list price for the applicable product, plus 8% per year annual support on those additional licences for the period of under-licensing.
Because Oracle's annual support fees increase by 8% per year, under-licensing that has persisted for multiple years compounds significantly. A deficit of 100 NUP licences identified in an audit covering the last three years will be priced as the licence fee for 100 NUP plus three years of support at the escalating 8% rate. For high-value products like Database Enterprise Edition, this arithmetic produces substantial audit settlement demands.
Organisations should audit their NUP position against the minimum calculation annually — ideally before Oracle's LMS team does it for them. For independent support in calculating your Oracle NUP minimum position or preparing for an upcoming renewal, visit our Oracle Knowledge Hub or contact our Oracle advisory team.