Named User Plus vs Processor Licensing (Oracle DB)

Named User Plus vs Processor Licensing (Oracle DB)

Oracle Database uses two main licensing metrics: Named User Plus (NUP) and Processor. Each model fits different environments and needs.

In simple terms, the Named User Plus model (Oracle NUP licensing) is Oracle’s per-user licensing approach, while the Processor model is Oracle’s per-core licensing approach.

This guide explains how each metric works, how to count licenses correctly under each, and how to choose the right one for your situation. The goal is to help you stay compliant with Oracle’s licensing rules and avoid unnecessary costs or audit risks.

Read our ultimate Oracle Database Licensing Guide.

Step 1 – What Named User Plus Licensing Means

Named User Plus (NUP) licensing means every person or system that can access the database needs a license. It doesn’t matter if they use it daily or rarely—if they have access, they count.

NUP is best for environments with a small, stable, and known set of users. If you can clearly identify all users and the count won’t grow much, NUP is usually the cheaper option. Importantly, NUP licenses must cover all your database environments (production, test, development, etc.).

Checklist: NUP Key Characteristics

• ✔ Count every user or process that can access the database
• ✔ 25 Named User Plus minimum per processor for Enterprise Edition (EE)
• ✔ 10 Named User Plus minimum per server for Standard Edition 2 (SE2)
• ✔ Must license all environments: production + non-production

Table: NUP Licensing Overview

Underestimating your user count can turn a Named User Plus license into a liability. If your organization grows or you forget about service accounts and third-party integrations, you could easily fall out of compliance. Always account for potential user growth when choosing NUP, and regularly review who has database access.

Step 2 – How to Count Users Correctly under NUP

Counting Named User Plus licenses can be tricky: Oracle’s license-counting rules require counting all users who can access the database, not just active ones.

Many teams mistakenly count only active application users, but Oracle expects everyone with permission to be included. Think of every person, device, or process that could touch your Oracle Database and make sure you include them in your count.

Checklist: NUP Counting Rules

• ✔ Count all users with a login (even if they rarely use it)
• ✔ Count system accounts, service accounts, and batch processes
• ✔ Count third-party application users who indirectly access the Oracle DB
• ✔ Count shared logins based on the number of people sharing them
• ✔ Document who counts as a “user” in your environment

Table: Common NUP Counting Mistakes

Never assume that only “active” users count. Even if someone runs a report only occasionally or a device queries data only once in a while, if they can connect to the database, Oracle will count them. NUP compliance often fails when companies underestimate the number of people and processes that have access to the data.

Read about options licensing, Oracle Database Editions & Options Licensing.

Step 3 – When Processor Licensing Makes More Sense

Oracle’s Processor licensing is based on server hardware rather than user count. You pay for the database by CPU cores (adjusted by Oracle’s core factor), not by the number of users.

The big benefit is you can have unlimited users – no need to track every individual accessing the database. This model is ideal when user populations are large or unpredictable (e.g., public web applications or global systems), because counting every user is impractical.

The downside is cost: Processor licenses are expensive, so if you only have a small number of users on a powerful server, it may be overkill.

However, if you anticipate thousands of users or can’t easily control who accesses the database, Processor licensing provides simplicity and peace of mind.

Checklist: Processor Licensing Features

• ✔ Unlimited users (no need to count individuals or devices)
• ✔ Cost is based on server cores × Oracle’s core factor
• ✔ Best for large, fluctuating, or external user populations
• ✔ Simplifies compliance management (fewer usage surprises)

Table: Processor Licensing Overview

Processor licensing buys simplicity at a higher price. You trade the effort of counting users for a bigger upfront spend.

This approach protects you from user-based audit issues – no matter how many people use the system, you’re covered – but be mindful that adding more CPU power (more cores or servers) will increase your Oracle licensing costs.

Step 4 – The Core Factor’s Role in Processor Licensing

Oracle’s Processor licensing uses a Core Factor Table to assign a multiplier to each CPU type. This core factor (0.25-1.0) determines how many licenses each core counts as. For example, many Intel/AMD chips have a 0.5 factor (two cores = one license), whereas Oracle’s SPARC chips have a 1.0 factor (one core = one license).

Total licenses required = (number of cores) × (core factor). Always consult Oracle’s core factor table when sizing licenses for new hardware.

This calculation also applies to any Oracle database options or packs – they must be licensed for the same cores.

Checklist: Core Factor Concepts

• ✔ More cores = more required licenses (after applying the core factor)
• ✔ Oracle’s core factors range roughly from 0.25 up to 1.0
• ✔ High-performance CPUs often have higher core factors (costlier per core)
• ✔ Core factor math applies to every Oracle option or pack as well

Table: Core Factor Examples

Hardware choices directly affect license costs under Processor licensing. A beefier server with more cores (or higher core-factor CPUs) will push your Oracle licensing fees up.

Many customers forget this and focus only on user counts or software features – but your infrastructure decisions can make a huge difference in how many licenses you need to buy.

Read about licensing in the cloud, Oracle Database Licensing in Cloud Environments.

Step 5 – How to Choose Between NUP and Processor

So which metric should you choose? It depends on the size of your user base, how easily you can count those users, and future growth. If your user population is small and well-defined, NUP will be cheaper.

If your user base is very large or unpredictable (for example, a public-facing app or a rapidly growing system), the Processor model is safer and more predictable cost-wise.

Choose NUP when you’re confident the user count will remain low and manageable. Choose Processor when you don’t want to worry about user numbers at all, or when counting users is more trouble than it’s worth. Here are some common scenarios:

Checklist: NUP Is Better When…

• ✔ User population is relatively small and well-defined
• ✔ User count stays stable over time
• ✔ Access is tightly controlled (no unknown or external users)
• ✔ You have powerful hardware but only a few users need the database

Checklist: Processor Is Better When…

• ✔ User count is very large, hard to track, or constantly changing
• ✔ The system supports external or anonymous users (e.g. public websites)
• ✔ The application requires high concurrency (many users at once)
• ✔ Future user growth is expected or cannot be accurately predicted

Table: Metric Choice Decision Matrix

The biggest mistake is choosing NUP when your user count could grow beyond control. If there’s uncertainty about user numbers, leaning toward Processor licenses can prevent unpleasant surprises later.

Conversely, if you clearly have a limited user group, NUP can save significant money. Always evaluate not just the current situation, but where things might be in a couple of years.

Step 6 – How Virtualization Changes the Decision

Virtualization can upend your licensing strategy. Oracle’s policies often force you into Processor licensing even if NUP looked cheaper, because Oracle doesn’t accept “soft” partitioning (like VMware) to limit licenses. In a VMware cluster, if any VM runs Oracle, you must license every host in the cluster. That makes NUP practically impossible there.

In public cloud environments, Oracle uses vCPU-to-core conversion formulas to calculate licenses, effectively treating cloud cores as on-prem processors.

In other words, a virtualized or cloud setup often negates the cost benefits of NUP and pushes you toward Processor licenses for compliance.

Checklist: Virtualization Considerations

• ✔ VMware or similar clusters often require Processor licensing for all hosts (Oracle doesn’t allow license slicing by soft partition)
• ✔ NUP counting becomes nearly impossible in multi-host virtual setups
• ✔ Public cloud licensing uses Oracle’s vCPU conversion rules (treating cloud CPUs like on-prem processors)

Table: Virtualization Impact

Virtualization can easily force your hand toward Processor licenses. We often see companies try to save money with NUP on virtual platforms, only to discover that Oracle’s rules require a much broader licensing scope that wipes out the savings. If your Oracle Database is deployed in a virtualized or cloud environment, review Oracle’s policies carefully. It might be more cost-effective (and safer compliance-wise) to use Processor licensing from the start in such cases.

Step 7 – Cost Considerations: NUP vs Processor

Even though both metrics can be cost-effective, their costs scale differently. NUP costs increase with each additional user, whereas Processor costs increase with each additional processor core.

This means NUP is usually cheaper for small, fixed user counts, but if your user base might grow rapidly, the Processor model could be more economical in the long run. Always compare both options for your scenario (considering future user growth and hardware upgrades) to find the break-even point where one becomes cheaper than the other.

Step 8 – 5 Expert Takeaways

To wrap up, here are five key takeaways from a former Oracle licensing strategist:

• Named User Plus (NUP) is effective only when your user count is low, stable, and tightly controlled. It falls apart if usage grows unexpectedly.
• Processor licensing eliminates worries about user counts, but exposes you to hardware-based costs (more cores = more expense).
• Virtualization often forces you into Processor licensing, even if NUP looks cheaper, because Oracle will make you license entire clusters or cloud instances.
• Always count every potential user or device – not just active users – under NUP. Every account with access needs a license to keep you compliant.
• The best metric choice is situational. It depends on your current needs and plans (user growth, hardware changes, architecture). Re-evaluate periodically as your environment evolves.

Choosing the right Oracle DB licensing metric is a strategic decision. The effort spent analyzing your user base and infrastructure up front can save significant pain later. By selecting the right metric (and keeping an eye on changes), you’ll avoid compliance pitfalls and control your Oracle licensing costs in the long term.

Read about our Oracle license management services

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit