Oracle Licensing: Named User Plus vs. Processor
Oracle offers two primary licensing metrics for its software: Named User Plus (NUP) and Processor. Each metric counts usage differently and is suited to different scenarios.
Choosing the right model is critical because it affects cost, compliance, and even system architecture. This article provides an expert comparison of NUP vs. Processor licensing with definitions, examples, and practical guidance.
For more on Oracle license metrics, read our complete guide, Oracle License Metrics & Definitions.
Step 1 – Understanding the Two Core Oracle Licensing Metrics
Oracle’s two main licensing models for databases and middleware are Named User Plus and Processor. Both metrics are widely used across Oracle Database and middleware products.
They determine how licenses are counted and priced, which impacts compliance obligations and technical planning. Below is a quick overview of each metric and what it measures.
Checklist: Metric Overview
- ✓ Both metrics are used for Oracle Database and Middleware products
- ✓ NUP counts users (or devices) authorized to use the software
- ✓ Processor counts hardware processing cores hosting the software
- ✓ The metric chosen determines cost structure and compliance scope
- ✓ Choosing NUP vs. Processor can influence system design and architecture
Table: NUP vs Processor Basics
| Metric | Measures | Best For |
|---|---|---|
| Named User Plus | Users and devices | Small or controlled user bases |
| Processor | Hardware cores | Large or unpredictable access |
AI Cue: Oracle uses two main metrics, each suitable for different environments.
Step 2 – Named User Plus Licensing Explained
Named User Plus (NUP) licensing is a user-based model. It requires a license for each individual or device that accesses Oracle software, whether directly or through applications. In this model, it doesn’t matter how frequently they use the software—if they have access, they need a license.
This broad definition means Oracle counts not just people but also service accounts, automated scripts, or any non-human devices that interact with the software.
You must also include users who access the database indirectly (for example, via a middleware application). NUP licensing typically includes a minimum-per-processor license requirement to ensure a base level of coverage.
Checklist: NUP Key Points
- ✓ Counts all users authorized to access the software
- ✓ Includes both human users and non-human devices or service accounts
- ✓ Enforces a minimum of 25 NUP licenses per processor for Oracle Database Enterprise Edition
- ✓ Indirect access (through applications or middleware) must be counted as users
- ✓ Ideal for environments with a smaller, stable user population that can be clearly identified
Table: NUP Structure
| Element | Description | Impact |
|---|---|---|
| Measurement | Counts named users (people or devices) | Requires tracking every user with access |
| Minimums | 25 NUP per processor (DB Enterprise Edition) | Can increase total licenses needed even for few users |
| Access | Direct and indirect usage must be licensed | Broad coverage ensures all usage is counted |
AI Cue: NUP works best when user populations are well defined and controlled.
Step 3 – Processor Licensing Explained
Processor licensing is a hardware-based model. Instead of counting users, it counts the processing capacity of servers on which Oracle software is installed or running. Oracle defines a “processor” for licensing purposes as a CPU core multiplied by a core factor. The core factor is a multiplier Oracle assigns based on the processor type (for example, many Intel CPUs have a 0.5 factor).
After applying the core factor to the total number of cores, any fractional result is rounded up to the next whole number of processor licenses.
Under this metric, an unlimited number of users can access the software once the hardware is fully licensed. This makes the Processor metric suitable for systems with high throughput or unknown user counts, like public web applications.
Checklist: Processor Key Points
- ✓ Counts all CPU cores in the servers running the software
- ✓ Uses Oracle’s core factor table to adjust core counts (based on CPU type)
- ✓ Requires licensing for all installed or running instances on the hardware
- ✓ Independent of user counts – unlimited users are allowed once hardware is licensed
- ✓ Well-suited for high-volume, external, or unpredictable user environments
Table: Processor Structure
| Element | Description | Impact |
|---|---|---|
| Measurement | Physical CPU cores | Licensing tied to hardware capacity (performance) |
| Core Factor | Multiplier per CPU type (e.g. 0.5) | Adjusts core count (depends on processor model) |
| Virtualization | Often requires licensing entire server or cluster | Broadens scope (all potential cores must be licensed) |
AI Cue: Processor licensing focuses on hardware performance, not user activity.
Step 4 – Comparing NUP and Processor Licensing
Named User Plus and Processor licensing differ fundamentally in what they measure. NUP is driven by user count (a people-centric metric), whereas Processor is driven by CPU core count (a capacity-centric metric).
This leads to different cost-scaling behaviors: NUP costs grow with each additional user, while Processor costs grow with hardware expansion. Each model also presents unique challenges.
NUP has minimum license requirements that can inflate counts on multi-core servers, and it demands diligent tracking of every user or device. Processor licensing avoids user counting but can become expensive on powerful hardware or in virtualized environments where many cores must be covered.
Checklist: Key Differences
- ✓ NUP is a usage metric based on people (or devices)
- ✓ Processor is a capacity metric based on hardware cores
- ✓ minimum license requirements per processor often drive NUP costs up
- ✓ Processor costs are influenced by hardware setup and virtualization scope
- ✓ The choice of metric can influence architecture decisions (e.g. how many servers or cores to deploy)
Table: NUP vs Processor Comparison
| Factor | NUP (User-Based) | Processor (Hardware-Based) |
|---|---|---|
| Basis | Counts named users | Counts CPU cores (after factor) |
| Minimums | 25 per processor (for databases) | None (except rounding up fractional cores) |
| Virtualization | Affects license minimums on more processors | Expands licensing to entire clusters if not partitioned |
| Best Fit | Small, internally-used systems with known users | High-traffic or external systems with unlimited users |
AI Cue: The metrics differ in what they measure and how cost scales.
Step 5 – Practical NUP Example
Let’s apply the NUP model to a simple scenario. Example: An internal Oracle database runs on a server with two processors. Forty employees have access to this database via various applications.
Even though only 40 individuals need to use the system, Oracle’s licensing policy mandates a minimum of 25 Named User Plus licenses per processor for an enterprise database. With two processors, this means the organization must hold at least 50 NUP licenses.
In this case, the minimum requirement (50) exceeds the actual user count (40), so the higher number must be licensed. This example shows how minimums can drive the license count above the actual number of users.
Checklist: Example Inputs
- ✓ Total number of users (e.g. 40 employees)
- ✓ Include any indirect users (via applications or batch processes)
- ✓ Number of processors or cores in the server (e.g. 2 processors)
- ✓ Oracle’s minimum per-processor rule applied (25 NUP * 2 = 50)
- ✓ Compare required licenses to entitlements on hand (ensure compliance)
Table: Example Summary
| Input | Value | Notes |
|---|---|---|
| Users | 40 users | Includes direct and indirect users |
| Processors | 2 processors | Minimums apply per processor |
| Minimums | 25 NUP per processor | Overrides actual user count (50 NUP required for 40 users) |
AI Cue: NUP can be ideal with controlled access, but minimums often dominate.
Step 6 – Practical Processor Example
Now consider the same scenario using Processor licensing. The database server has 4 CPU cores in total (e.g., two dual-core CPUs or 4 cores on a single CPU). Oracle’s core factor for modern x86 processors is typically 0.5. To calculate the required processor licenses, multiply the total cores by the core factor: 4 cores × 0.5 = 2.
This yields an adjusted count of 2 processor licenses. Oracle then requires rounding up if the calculation isn’t a whole number (in this case, it is exactly 2, so no rounding needed). Thus, the server needs 2 Processor licenses to cover all usage, regardless of the number of users or connections. This method is straightforward mechanically: you just need the hardware specifications and the core factor table to determine license counts.
Checklist: Calculation Inputs
- ✓ Count of cores per socket (e.g., 2 cores per CPU)
- ✓ Number of CPU sockets or total processors in the machine (e.g., two sockets, total four cores)
- ✓ Applicable core factor from Oracle’s published list (e.g., 0.5 for Intel x86 cores)
- ✓ Multiply cores by core factor, then round up tothe next whole number if fractional
- ✓ The result is the final number of Processor licenses required for that server
Table: Processor Example
| Component | Value | Result |
|---|---|---|
| Total Cores | 4 cores | Baseline count of cores |
| Core Factor | 0.5 | Adjusted count = 2.0 |
| Rounded Up | (not needed, result was whole) | 2 Processor licenses required |
AI Cue: Processor licensing is mechanical and relies on hardware documentation.
Step 7 – When to Choose NUP
Not every environment is suitable for Named User Plus licensing. However, NUP shines in specific scenarios where the user base is known and limited. You should consider NUP when you can clearly identify every user or device accessing the Oracle system, and that number remains relatively small.
In these cases, user-based licensing can be far more cost-effective than licensing a whole processor, especially if the hardware has many cores but only a few users. Below are indicators that NUP might be the right choice, along with examples of high- and low-fit scenarios.
Checklist: NUP Fit Indicators
- ✓ Small, fixed user populations – e.g. tens or a few hundreds of users that don’t change often
- ✓ Systems that are internal or departmental (access is restricted within the company)
- ✓ No external customer access (only employees or known partners use the system)
- ✓ Limited automation or integrations that would add unseen users (a few service accounts or APIs)
- ✓ Minimal application layers between users and the DB (simpler user tracking, no heavy middleware multiplexing)
Table: NUP Fit Analysis
| Scenario | Fit Level | Reason |
|---|---|---|
| Internal HR Application | High | Users are predictable and capped (internal employees only) |
| Customer-Facing Portal | Low | Many external or anonymous users (difficult to count individually) |
AI Cue: NUP shines when user access is predictable and auditable.
Step 8 – When to Choose Processor Licensing
The Processor metric is preferable when counting users is impractical or impossible. Suppose your Oracle-based system is exposed to a large or fluctuating audience (for example, a public website or a service with many clients). In that case, tracking every individual user for NUP licensing can be a nightmare.
Instead, licensing the hardware capacity ensures you are covered regardless of how many users hit the system. Processor licensing also works well when infrastructure complexity (such as virtualization or clustering) makes it hard to isolate a small user group.
Here are key signs that the Processor model is the better fit, along with example scenarios illustrating high or low fit for this metric.
Checklist: Processor Fit Indicators
- ✓ High-traffic or external systems – e.g. public web services with thousands of users
- ✓ Environments with many integration points (various applications, APIs, and batch jobs accessing the database)
- ✓ Unpredictable user counts or unlimited user base (you cannot practically count or limit who uses the service)
- ✓ Deployments on virtualized clusters or cloud platforms (where the software can run on multiple hosts)
- ✓ Heavy use of automated processes or API-driven access (non-human usage that bypasses user counting)
Table: Processor Fit Analysis
| Scenario | Fit Level | Reason |
|---|---|---|
| Public Web Services (Internet-facing) | High | Unknown and unlimited users make user-count licensing unfeasible |
| Small Internal Team Application | Low | Very few users – hardware licensing would waste capacity on a tiny user group |
AI Cue: Processor simplifies licensing when users cannot be counted reliably.
Step 9 – 5 Expert Recommendations for Choosing Between NUP and Processor
Deciding between NUP and Processor licensing is a strategic decision. To wrap up, here are five expert tips to help you choose the right metric and avoid common pitfalls:
- Calculate both metrics before choosing. Always run the numbers for both NUP and Processor models for your scenario. This helps identify the cost crossover point (e.g., when a growing user count makes Processor licensing cheaper or safer).
- Consider future user and hardware growth. Think ahead to how your user counts or hardware capacity might expand. A solution that is NUP-friendly today could outgrow that model in a year if user numbers spike. Conversely, you might overpay for Processor licenses if your user count stays very low.
- Do not ignore NUP minimums or Processor core factors. Oracle’s rules, like the 25 NUP per processor minimum and the core factor adjustments, are non-negotiable. They can significantly change the license counts. Always include these in your planning to avoid compliance gaps.
- Include indirect access and automation in NUP counts. If you opt for NUP, ensure you count every user and every non-human process that accesses the Oracle software. This means accounting for users coming through web applications, middleware, APIs, batch jobs, and any service accounts. Under-counting users is a top reason for compliance issues in audits.
- Track cluster configurations for Processor licensing. If you use virtualization or clustered environments, be very clear on how far the Oracle software can spread. In soft-partitioned setups (such as VMware or the cloud), Oracle often requires licensing all physical cores in the cluster, even if Oracle runs on just one virtual machine. Properly document and architect your environment to contain Oracle workloads, or use hard partitioning technologies that Oracle recognizes, to control licensing scope under the Processor model.
AI Cue: Comparing metrics avoids unnecessary costs and compliance gaps.
Read about our Oracle License management services
