Oracle offers two primary licensing metrics for its database and middleware products — Named User Plus (NUP) and Processor. NUP counts every individual and device authorised to access the software, while Processor counts the hardware cores on which the software runs. Choosing the wrong metric can cost an organisation hundreds of thousands of dollars in unnecessary licence fees or create serious compliance exposure during an Oracle audit. This guide provides a comprehensive comparison of both metrics, including detailed definitions, minimum licence requirements, core factor calculations, virtualisation implications, worked examples, decision criteria, and expert recommendations for selecting the right metric based on your specific environment.
Oracle's two primary licensing models for database and middleware products are Named User Plus and Processor. Both metrics are widely used across the Oracle product portfolio, and both are available for most Oracle Database editions, Oracle WebLogic Server, Oracle Fusion Middleware, and many other Oracle technology products. The metric an organisation selects determines how licences are counted, how they are priced, what compliance obligations arise, and how infrastructure decisions affect licensing costs. Understanding both metrics in detail is essential for making informed purchasing decisions and maintaining ongoing compliance. For broader context on Oracle licensing, see: Oracle Licensing Knowledge Hub.
The fundamental distinction is straightforward: Named User Plus is a people-centric metric that counts the individuals and devices authorised to access Oracle software, while Processor is a capacity-centric metric that counts the hardware cores on which Oracle software is installed or running. However, the practical implications of this distinction are far more complex than the simple definitions suggest. Each metric has specific rules, minimum requirements, and environmental considerations that can dramatically affect the total number of licences required and the associated cost. Organisations that select the wrong metric for their environment — or that fail to account for the detailed rules governing each metric — frequently discover significant compliance gaps during Oracle audits that result in unexpected licence purchases and back-dated support fees.
Both metrics can be applied to the same Oracle products, and Oracle allows customers to choose between them at the point of purchase. However, changing the metric after purchase is not straightforward — it typically requires a new licence transaction or a contract amendment with Oracle. This means the initial decision has long-term consequences, and organisations should invest appropriate time and analysis in making the right choice. The following sections explain each metric in detail, compare them directly, provide worked examples, and offer practical guidance for selecting the right metric based on specific environmental characteristics.
Named User Plus (NUP) licensing is a user-based model that requires a licence for each individual person or device authorised to access Oracle software, regardless of how frequently that access occurs. The definition of "access" under Oracle's licensing terms is deliberately broad — it encompasses direct database connections, access through middleware applications, access via web interfaces, automated batch processes, service accounts, API integrations, and any other mechanism through which a person or device interacts with the Oracle software. If an entity has the ability to access the Oracle software, it requires a Named User Plus licence, even if that access is infrequent, indirect, or automated.
The breadth of this definition is one of the most important aspects of NUP licensing for compliance purposes. Oracle counts not only employees who log in directly to the database, but also users who access Oracle data through third-party applications, users who access Oracle-powered web portals, service accounts that perform automated tasks, monitoring tools that query the database, and any non-human devices or processes that interact with the Oracle software in any way. Organisations that fail to count indirect users and automated processes frequently discover significant compliance gaps during audits, because the actual number of entities accessing Oracle software is often substantially higher than the number of people who are consciously aware that they are using an Oracle product.
Processor licensing is a hardware-based model that counts the processing capacity of servers on which Oracle software is installed or running, rather than counting the individuals or devices that access the software. Oracle defines a "processor" for licensing purposes as the number of physical CPU cores in a server multiplied by a core factor — a decimal multiplier that Oracle assigns to each processor architecture based on its relative performance characteristics. The core factor table is published by Oracle and updated periodically as new processor types enter the market. For the current core factor values, see: Oracle Processor Core Factor Table.
The core factor mechanism means that the number of processor licences required is not simply equal to the number of physical cores in the server. For most Intel and AMD x86 processors — which represent the vast majority of enterprise server deployments — the core factor is 0.5, meaning that each physical core counts as half a processor licence. A server with 16 physical Intel cores would therefore require 8 processor licences (16 cores × 0.5 core factor = 8 processor licences). SPARC processors typically carry a core factor of 0.25 or 0.5 depending on the specific model, while IBM POWER processors carry a factor of 1.0. After applying the core factor, any fractional result is rounded up to the next whole number of processor licences.
The most significant advantage of Processor licensing is that once the hardware is fully licensed, an unlimited number of users can access the Oracle software without any additional licensing obligation. This makes the Processor metric particularly suitable for environments where the user population is large, unpredictable, or difficult to count — such as internet-facing applications, customer portals, public web services, or systems with extensive integration and automation that makes user counting impractical. However, Processor licensing can become expensive on powerful servers with many cores, and virtualisation introduces significant complexity that can dramatically expand the licensing scope.
| Processor Architecture | Typical Core Factor | Example: 16-Core Server Requires |
|---|---|---|
| Intel / AMD x86 | 0.5 | 8 processor licences |
| Oracle SPARC T-series | 0.25 | 4 processor licences |
| Oracle SPARC M-series | 0.5 | 8 processor licences |
| IBM POWER | 1.0 | 16 processor licences |
| Core factors reduce licence counts for most modern x86 environments but increase costs on IBM POWER | ||
Named User Plus and Processor licensing differ fundamentally in what they measure and how costs scale as an organisation's environment grows. NUP costs grow linearly with each additional user or device that gains access to the Oracle software, while Processor costs grow with hardware expansion — adding cores, servers, or expanding virtualisation clusters. Each model presents unique advantages and unique compliance challenges that organisations must understand before selecting a metric.
NUP licensing costs increase with every additional user, device, or automated process that accesses Oracle software. The minimum licence requirements per processor establish a cost floor that applies regardless of actual user counts — on multi-core servers, these minimums can drive the required licence count significantly above the actual number of users. NUP is most cost-effective when the user population is small relative to the hardware capacity, and when the organisation can accurately track and control who has access to the Oracle environment.
Processor licensing costs increase with hardware expansion — more cores, more servers, or broader virtualisation clusters all increase the licence count. The core factor provides some relief for common x86 architectures, but the licensing scope in virtualised environments (where Oracle may require licensing the entire physical cluster, not just the virtual machines running Oracle) can dramatically increase costs. Processor licensing is most cost-effective when the user population is large relative to the hardware footprint, or when users cannot be practically counted or controlled.
| Factor | Named User Plus (User-Based) | Processor (Hardware-Based) |
|---|---|---|
| What it measures | Named individuals and devices | Physical CPU cores (adjusted by core factor) |
| Minimum requirements | 25 NUP per processor (DB EE) | None beyond rounding up fractional cores |
| User count impact | Directly proportional — more users = more licences | None — unlimited users once hardware is licensed |
| Hardware impact | Minimums increase with more processors | Directly proportional — more cores = more licences |
| Virtualisation impact | Affects minimum calculations on underlying hardware | May require licensing entire physical cluster |
| Compliance complexity | High — must track every user including indirect access | Moderate — must track hardware and virtualisation scope |
| Best suited for | Small, known, internal user populations | Large, external, or unpredictable user populations |
To illustrate how NUP licensing works in practice, consider the following scenario. A mid-size organisation operates an internal Oracle Database Enterprise Edition instance used by its finance department. The database runs on a server with two Intel Xeon processors, each containing 8 physical cores (16 cores total). Forty-five finance team members access the database — some directly through SQL tools, others through the organisation's financial reporting application that connects to the Oracle database. Additionally, three automated batch processes run nightly reconciliation jobs against the database, and two monitoring agents query the database for performance metrics. The total user count is therefore 45 human users plus 5 non-human processes, totalling 50 Named User Plus licences based on actual usage.
However, Oracle's minimum licence requirement for Database Enterprise Edition is 25 NUP per processor. With 16 cores and a 0.5 core factor, the server has 8 processor equivalents for minimum calculation purposes. The minimum is therefore 8 × 25 = 200 NUP licences. Since the minimum (200) exceeds the actual user count (50), the organisation must purchase 200 NUP licences — four times the number of actual users. This example demonstrates how NUP minimums can dominate the licence calculation on multi-core servers, making NUP licensing less cost-effective than it initially appears for environments with small user populations running on powerful hardware.
Environment: Oracle Database Enterprise Edition on a 2-socket Intel Xeon server (16 cores total). 45 human users (direct and indirect), 3 batch processes, 2 monitoring agents — 50 total named users.
Core factor calculation: 16 cores × 0.5 (Intel core factor) = 8 processor equivalents.
Minimum requirement: 8 processors × 25 NUP minimum = 200 NUP licences required.
Now consider the same server licensed under the Processor metric for comparison. The server has 16 physical Intel Xeon cores with a core factor of 0.5. The processor licence calculation is straightforward: 16 cores × 0.5 core factor = 8 processor licences. This covers all usage on the server regardless of the number of users — the 45 finance team members, the 3 batch processes, the 2 monitoring agents, and any future users who gain access are all covered by the 8 processor licences without any additional licensing obligation.
The cost comparison between the two metrics depends on the per-licence price for each metric. Oracle Database Enterprise Edition list price (for reference only — actual prices vary based on negotiated discounts) is approximately $47,500 per processor licence and approximately $950 per NUP licence. At these list prices, 8 processor licences would cost $380,000, while 200 NUP licences would cost $190,000. In this specific scenario, NUP licensing is cheaper despite the minimum requirement inflating the count to 200 — because the hardware is substantial but the minimum-driven NUP count is still below the cost crossover point. However, if the server were larger (for example, 4 sockets with 32 cores), the minimum would be 16 × 25 = 400 NUP at $380,000, matching the Processor cost exactly, and any additional cores would tip the balance in favour of Processor licensing.
| Metric | Calculation | Licences Required | List Price (Illustrative) |
|---|---|---|---|
| Named User Plus | Max(50 actual users, 200 minimum) = 200 | 200 NUP | $190,000 |
| Processor | 16 cores × 0.5 factor = 8 | 8 Processor | $380,000 |
| In this scenario NUP is cheaper — but the crossover point depends on server size, user count, and negotiated discounts | |||
Named User Plus licensing is the better choice in environments where the user population is small, well-defined, stable, and controllable. The key requirement is that the organisation must be able to accurately identify and count every individual and device that has access to the Oracle software — including indirect access through applications, APIs, and automated processes. If the user population meets these criteria and the NUP count (including minimums) results in a lower cost than the equivalent Processor licence, NUP is the right metric. The following indicators suggest that NUP licensing is a strong fit for a particular Oracle deployment.
Oracle deployments that serve a specific internal department — finance, HR, supply chain, project management — with a known and stable group of users. These environments typically have predictable user counts, limited external access, and straightforward user tracking. The user population is usually well below the threshold where Processor licensing becomes more cost-effective, making NUP the clear winner on both cost and compliance simplicity. Examples include internal ERP modules, departmental reporting databases, and back-office administrative systems.
Oracle deployments serving a broader but still identifiable user population — for example, a company-wide application with several hundred users. NUP can still be cost-effective in these scenarios, but the organisation must monitor user growth carefully and recalculate the cost comparison periodically. If the user count approaches the crossover point where Processor licensing becomes cheaper, a metric change may be warranted. The compliance burden of tracking all users across a larger population is also higher, requiring more robust ITAM processes.
Oracle deployments that serve external customers, partners, or the public — or internal systems where the user population is growing rapidly or unpredictably — are generally poor candidates for NUP licensing. The difficulty of counting and controlling external users, combined with the risk that user growth will push costs above the Processor equivalent, makes NUP impractical and potentially more expensive. Organisations in this category should evaluate Processor licensing as the default choice.
Processor licensing is the better choice when counting users is impractical, impossible, or when the user population is so large that NUP licensing would be more expensive than licensing the hardware. The Processor metric eliminates the compliance burden of user tracking entirely — once the hardware is licensed, any number of users can access the Oracle software without additional licensing obligations. This simplicity is particularly valuable in complex environments with extensive integration, automation, and virtualisation where identifying every entity that accesses Oracle software would be extremely difficult and error-prone.
Virtualisation introduces significant complexity to both NUP and Processor licensing, but it affects each metric differently and is often the deciding factor in choosing between them. Under Oracle's licensing policies, the impact of virtualisation depends on whether the partitioning technology used is recognised by Oracle as a "hard partitioning" method (which limits the licensing scope to specific physical resources) or is treated as "soft partitioning" (which typically requires licensing the entire physical host or cluster, not just the virtual machines running Oracle).
Most common enterprise virtualisation technologies — including VMware vSphere, Microsoft Hyper-V, and KVM — are classified by Oracle as soft partitioning methods. This means that if Oracle software runs on a virtual machine within a VMware cluster, Oracle may require licensing all physical cores across the entire cluster, even if Oracle is confined to a single small virtual machine. This dramatically affects both metrics: under Processor licensing, the core count expands to include the entire cluster, while under NUP licensing, the minimum licence requirements must be calculated against the total processor count of the entire cluster. Oracle-recognised hard partitioning technologies — such as Oracle VM Server (OVM), Solaris Zones, and IBM LPAR with specific configurations — can limit the licensing scope to the physical resources allocated to the Oracle workload.
When using Oracle-recognised hard partitioning (Oracle VM, Solaris Zones, IBM LPAR with dedicated resources), licences are only required for the physical cores allocated to the Oracle partition. This limits both the Processor licence count and the NUP minimum calculation to the allocated resources. Hard partitioning is the most effective way to control Oracle licensing costs in virtualised environments, but it requires using specific technologies that Oracle formally recognises.
When using soft partitioning (VMware, Hyper-V, KVM), Oracle may require licensing all physical cores in the entire cluster or host — not just the resources allocated to the Oracle virtual machine. This can increase Processor licence requirements by orders of magnitude and inflate NUP minimums correspondingly. Organisations using VMware or similar platforms must carefully architect their Oracle deployments to manage this licensing exposure, or consider migrating Oracle workloads to hard-partitioned environments.
Selecting between Named User Plus and Processor licensing is a strategic decision with long-term financial and compliance implications. The following recommendations are based on two decades of enterprise Oracle licensing advisory experience and address the most common decision factors and pitfalls that organisations encounter when choosing between the two metrics.
Run a full licence calculation for both NUP and Processor for every Oracle deployment before making a purchasing decision. Include all users (direct, indirect, automated), all hardware (cores, sockets, cluster scope), and all applicable minimums and core factors. Many organisations default to NUP because they assume a small user count means lower cost, only to discover that minimums on multi-core servers or virtualised clusters make Processor licensing cheaper. The only way to make an informed decision is to compare the fully calculated costs for both metrics side by side.
Evaluate not only the current environment but also the anticipated trajectory over the licence term. A deployment that is NUP-friendly today could outgrow the metric within a year if user numbers increase significantly. Conversely, planned hardware upgrades or virtualisation changes could shift the Processor calculation unfavourably. Consider the three-to-five-year outlook for user growth, hardware refresh cycles, and infrastructure modernisation before selecting a metric, and build flexibility into Oracle contract terms to accommodate potential metric changes if the environment evolves. For contract negotiation support, see: Oracle Contract Negotiation Service.
Oracle's minimum NUP requirements per processor and its virtualisation partitioning rules are non-negotiable contractual terms that can dramatically change the licence calculation. Organisations that calculate NUP based only on actual user counts — without applying the per-processor minimums — or that calculate Processor licences based only on the virtual machine allocation — without considering soft partitioning scope — will discover significant compliance gaps during audits. Always apply the full set of Oracle's licensing rules to both metrics before comparing costs.
If selecting NUP licensing, conduct a thorough access audit that identifies every entity accessing the Oracle software — human users (direct and indirect), service accounts, batch processes, monitoring tools, API integrations, and any other automated or non-human access. Under-counting users is the single most common cause of NUP compliance failures in Oracle audits. Establish ongoing processes to track user additions and removals, and recalculate the NUP count periodically to ensure continued compliance as the environment evolves.
Oracle licensing metric selection involves complex interactions between user populations, hardware configurations, virtualisation architectures, Oracle's specific rules and policies, and negotiated contract terms. Engaging independent Oracle licensing expertise before making a purchasing decision — or before an Oracle audit — ensures that the organisation selects the most cost-effective metric, calculates licence requirements accurately, and negotiates contract terms that protect against future changes. Independent advisors who are not affiliated with Oracle provide objective guidance that prioritises the customer's interests. See: Oracle Licence Management Services.
The choice between Named User Plus and Processor licensing is not a one-size-fits-all decision — it depends on the specific characteristics of each Oracle deployment, including the user population, hardware configuration, virtualisation architecture, growth expectations, and the organisation's ability to track and control access. NUP licensing is typically more cost-effective for small, well-defined, internal user populations on modest hardware, while Processor licensing is typically more cost-effective for large, external, or unpredictable user populations where counting individual users is impractical. However, the detailed rules governing each metric — particularly NUP minimums and virtualisation scope — can produce counterintuitive results that only become apparent through careful calculation and analysis.
The most important recommendation is to always calculate both metrics fully before committing to a purchasing decision, and to revisit the calculation periodically as the environment evolves. Organisations that invest the time to understand both metrics, calculate both costs accurately, and select the right metric for each deployment avoid the most common and most costly Oracle licensing mistakes — paying significantly more than necessary for the wrong metric, or discovering a compliance gap during an audit that could have been prevented with proper planning. For organisations that need assistance with metric selection, licence calculations, or Oracle contract negotiations, independent advisory firms like Redress Compliance provide the expertise and objectivity needed to make confident, informed licensing decisions.
Named User Plus (NUP) counts every individual person and device authorised to access Oracle software, while Processor licensing counts the physical CPU cores in servers running Oracle software (adjusted by Oracle's core factor). NUP costs scale with the user population, while Processor costs scale with hardware capacity. Under Processor licensing, an unlimited number of users can access the software once the hardware is fully licensed.
Oracle Database Enterprise Edition requires a minimum of 25 Named User Plus licences per processor (where "processor" is calculated using the core factor). Oracle Database Standard Edition 2 has a minimum of 10 NUP per server. These minimums apply regardless of the actual number of users — if the minimum exceeds the actual user count, the higher number must be licensed.
The core factor is a decimal multiplier that Oracle assigns to each processor architecture to determine the number of processor licences required. Most Intel and AMD x86 processors have a core factor of 0.5, meaning each physical core counts as half a processor licence. IBM POWER processors have a factor of 1.0 (each core equals one full licence). The core factor is applied to the total physical core count, and the result is rounded up to determine the number of processor licences required.
Yes. Oracle requires NUP licences for all users who access Oracle software, whether directly (logging in to the database) or indirectly (accessing Oracle data through middleware, applications, web interfaces, APIs, or any other intermediary). Failing to count indirect users is one of the most common causes of compliance findings in Oracle audits.
Virtualisation can significantly expand Oracle licensing scope under both metrics. With soft partitioning technologies (VMware, Hyper-V, KVM), Oracle may require licensing all physical cores in the entire host or cluster — not just the resources allocated to the Oracle virtual machine. Oracle-recognised hard partitioning technologies (Oracle VM, Solaris Zones, IBM LPAR) can limit the scope to allocated resources. This affects both the Processor core count and the NUP minimum calculations.
Processor licensing is typically more cost-effective when the user population is large, external-facing, or unpredictable — making NUP counting impractical or expensive. It is also often cheaper when NUP minimums on multi-core servers or virtualised clusters inflate the NUP count well above the actual user number. The only way to determine which is cheaper for a specific environment is to fully calculate both metrics and compare the total costs.
Switching metrics after purchase is not straightforward — it typically requires a new licence transaction or a contract amendment with Oracle. This means the initial metric selection has long-term consequences. Organisations should invest appropriate analysis in making the right choice at the point of purchase and build flexibility into Oracle contract terms to accommodate potential metric changes if the environment evolves significantly.
Redress Compliance provides independent advisory on Oracle licensing metric selection, licence calculations, audit defence, and contract negotiation. No Oracle partnerships, reseller relationships, or referral arrangements.