Oracle Named User Plus vs. Processor Licensing
Oracle Database offers two primary licensing metrics for on-premises software: Named User Plus (NUP) and Processor licenses. Choosing the right model can have significant cost and compliance implications for enterprise IT.
This article provides CIOs, CTOs, and procurement leaders with a comparison of NUP vs. Processor licensing.
It defines each metric, illustrates how they’re applied (including minimums like the 25 Named User Plus per processor rule), and gives guidance on when to use one over the other.
Real-world examples (with pricing) are included to help you make an informed decision that optimizes your Oracle licensing spend while meeting usage needs.
Read Optimizing Oracle Database Licensing Costs: Strategies for Enterprise CIOs.
Oracle’s Two License Metrics
Oracle’s on-premise database licenses are sold under two main metrics:
- Processor Licensing: You pay per processing power (CPU cores) on the database server. This model allows unlimited users to access the database, since you’re licensing the machine’s capacity rather than individuals.
- Named User Plus Licensing: You pay based on the number of distinct users (and/or devices) that access the database. This model ties the license to people (or non-human-operated devices) rather than hardware and is cost-effective when user counts are low or controlled.
Both metrics grant the same software usage rights; they are simply two ways to measure the usage for pricing.
You choose one metric or the other for a given Oracle deployment, not both. Each has specific rules and scenarios that make sense.
Key Considerations:
- Edition Compatibility: Both metrics can be used for Oracle Database Enterprise Edition (EE) and Standard Edition 2 (SE2) licenses. (One exception: Oracle Personal Edition, a rarely used edition, is only available under Named User Plus since it’s for single-user environments.)
- Mixing Metrics: You cannot mix metrics on the same deployment. You must license a given database server (or clustered system) entirely by processors or NUP. However, you can use different metrics for different servers in your organization. For example, you might license a production database by Processor and a separate development database by NUP.
- License Minimums: Oracle imposes minimum license counts in both models to prevent under-licensing. The most important one: 25 Named User Plus per processor (core) for Enterprise Edition. This means even if you have, say, 5 users, if the database runs on a server that would require 2 Processor licenses, Oracle expects at least 50 NUP licenses (25 per proc × 2). We’ll explore this further below.
Understanding each model in depth will help determine which to choose for a given system.
Named User Plus (NUP) Licensing Explained
A Named User Plus license is for each unique user or device accessing the Oracle Database.
In Oracle’s terms, a “user” is not just a person with a login account but can also be a device, sensor, or application process that connects to the database. Essentially, any endpoint interacting with the database counts as a “Named User” needing a license.
Key points of NUP licensing:
- Counting Users/Devices: You must count all individuals and non-human-operated devices that use the database, directly or indirectly. For example, suppose 100 employees use an internal application that connects to an Oracle Database. In that case, those 100 employees count as Named Users, even if the application uses a single service account to connect (Oracle calls this “multiplexing” – it does not reduce the count).
- Unlimited Servers – No, per Environment: NUP licenses are specific to the server or environment. You can’t buy 50 Named User Plus licenses and spread them arbitrarily across any number of databases or servers. The licenses must cover each deployed Oracle Database installation. If you have two separate database servers, each must meet the minimum NUP count and have its own NUP licenses (though the same user accessing both could count towards both environments’ totals).
- License Minimums (Enterprise Edition): Oracle requires a minimum of 25 Named User Plus licenses per processor, as calculated for that server. The “processor” in this context respects Oracle’s core factor. For example, a server with eight physical cores of Intel (0.5 core factor) counts as four processors in Oracle’s eyes, so minimum NUP = 4 × 25 = 100 Named Users, even if only 20 people use the DB. For Standard Edition 2, the minimum is fixed at 10 Named Users per server (since SE2 is limited to at most two sockets anyway).
- Example – Small User Base: Suppose a small HR application has 20 employees using it and runs on a single-socket server (say 8-core CPU, core factor 0.5 = 4 Oracle processors). Enterprise Edition on that server by NUP would mandate a minimum of 100 NUP licenses. Even though only 20 people use it, you must license 100 Named Users to satisfy Oracle’s rules. The list price of $950 per NUP is $95,000, which interestingly equals 2 Processor licenses worth (we’ll examine break-even points later).
- When is NUP Ideal?: NUP licensing works best when you have a small, known user population well under the equivalent threshold of processor licensing. Typical scenarios: development and test environments (with a handful of DBAs or developers), departmental applications used by maybe 10-50 people, or any system where you can confidently count every user, and that number is low. NUP is also common for internal systems with restricted access (not public-facing).
One must also consider administrative overhead: NUP licensing means you should have processes to keep track of the number of users accessing the database. You may need to true-up if new user groups are added (buy more NUP licenses).
If a system grows from 50 users to 500, NUP might become less economical than switching to Processor licensing.
Read Oracle Database High Availability & Disaster Recovery Licensing: The 10-Day Rule.
Processor Licensing Explained
A Processor License allows an unlimited number of users to access the Oracle Database on a server, but you must license the processing cores of the server.
Oracle’s definition of “processor” for licensing is based on physical cores and a core factor multiplier:
- Calculating Processors: Oracle provides a Core Factor Table that assigns a factor to each CPU type. Most modern x86 chips have a factor of 0.5. To determine the number of processor licenses needed, multiply the total physical cores by the factor and round it up. For example, a server with 16 cores of Intel (0.5 factor) equals 8 Processor licenses. A server with 24 cores of AMD (0.5 factor) equals 12 Processor licenses.
- Full Use Rights: With processors licensed, you don’t worry about how many users or devices connect. It could be 10 or 10,000 users – it’s all covered as long as the hardware is licensed. This is essential for systems like public web services or large enterprise applications with high or unbounded user counts.
- Minimums: The processor metric inherently covers any number of users, so there’s no user minimum to track. However, a hardware minimum exists for Standard Edition 2 – if you have a multi-socket server beyond SE2’s limits, you can’t use SE2 at all (for instance, a 4-socket server must use Enterprise Edition). For Enterprise Edition, any fractional number from the core calculation is rounded to the next whole processor license.
- Example – High Load System: Consider a customer-facing portal where user counts can be in the thousands or fluctuate. This runs on a 2-processor server (maybe 16 cores total, factor 0.5, so 8 Processor licenses needed). By licensing those 8 Processors, you’re covered no matter if 50 or 50,000 users use the system. At a list price of $47,500 per processor, eight licenses cost $380,000. Attempting NUP for 50,000 users would be impossible (and against Oracle rules, since you’d fall below per-core minimums or have astronomical costs).
- When is a Processor Ideal?: Processor licensing is the go-to choice for large user populations or unknown user counts. If counting users is impractical or if the user base might exceed roughly 50 per Oracle processor, processor licensing usually becomes more cost-effective and simpler. It’s also the only option for externally facing systems or infrastructure where you cannot tally every end user (e.g., an e-commerce website’s DB, or a middleware that many devices call into).
- Multi-Core High-End Servers: Be mindful that processor licensing scales with core count on core-dense servers. If you have a 64-core server (with factor 0.5 = 32 licenses), that single server can host a lot of workload, but costs 32 licenses. Sometimes, splitting workloads onto smaller servers and using NUP could, in theory, save money if each smaller server’s user base is limited. But that adds complexity and is rarely done solely for that reason; performance needs often drive hardware choices.
Minimums and the 25-NUP-Per-Processor Rule
As mentioned, Oracle mandates at least 25 Named User Plus per “Oracle processor” for Enterprise Edition.
Let’s clarify with a concrete scenario and then see where the breakeven lies between NUP and Processor cost:
- Scenario: Server with eight cores, Intel x86. Core factor = 0.5, so Oracle counts 4 Processors on this server.
- Processor licensing needed: 4 Processor licenses.
- NUP licensing need: Minimum 4 × 25 = 100 Named User Plus licenses, even if actual users <100.
- List price comparison: Oracle EE list is $47,500 per Processor license, so 4 Proc = $190,000. User Plus is $950 each, so 100 NUP = $95,000.
At a minimum, 100 NUP costs about half the cost of 4 Processor licenses for the same server. This suggests that NUP can save money if you have a small user count. However, in this example, Oracle doesn’t let you buy less than 100 NUP, even if you only have 10 users; they enforce that floor.
The breakeven point regarding user counts per processor (at list price) is roughly 50 Named Users per 1 Processor license. Why? Because 50 NUP × $950 = $47,500, which equals 1 Processor license cost. Oracle’s minimum of 25 NUP per processor effectively sets the breakeven at double that minimum if we consider cost alone:
- Fewer than ~50 users per processor -> NUP might be cheaper (costing less than a proc license).
- More than ~50 users per processor -> Processor license likely cheaper.
Of course, with Oracle’s typical 25-user minimum, you rarely will license exactly at the breakeven; you’ll either be at the minimum (if actual users <25 per proc, you still pay for 25) or well above.
Important: Oracle’s list prices are often discounted in enterprise deals (20%, 50%, or more off). Discounts usually apply equally to NUP and Processor in percentage terms. This means the cost ratio generally stays similar. So the decision point (user count vs core count) isn’t usually altered by discounts—both metrics get cheaper by the same proportion.
Choosing the Right Model (When to Use NUP vs. Processor)
Selecting NUP or Processor comes down to balancing user count vs. hardware size, and understanding current and future usage of the database:
Choose Named User Plus if:
- You have a limited, known user base that will stay relatively small. For instance, an internal application for 30 analysts, a development database used by five engineers, or a manufacturing system used by 40 plant managers.
- The deployment is on modest hardware (a few processors). With fewer processors, the NUP minimums won’t force an excessively high count. For example, a single-socket server (which counts as 1 or 2 Oracle processors, depending on cores) has a lower NUP minimum (25 or 50).
- You are willing and able to track user counts. You’ll need processes to ensure new users aren’t added without considering license entitlements.
- The budget is tight, and every license dollar counts. NUP can squeeze more value if user counts are low because you’re not paying for unused capacity.
Choose Processor licensing if:
- The user population is or will be large or indeterminate, e.g., in customer-facing systems, company-wide systems (like Oracle EBS itself or large ERP databases), or any scenario where counting every user is impractical.
- The server has many CPU cores or is in a cluster. High-performance systems often come with many cores, which suggests they support many users or heavy workloads, usually pointing to Processor licensing as more appropriate.
- You want simplicity and future-proofing. Processor licenses give flexibility to add users without needing to buy more licenses (until you scale up hardware). If you expect growth, this model avoids incremental purchases each time the user count grows.
- You need to ensure compliance in a scenario with integrations or unknown connections. Sometimes, indirect users (through third-party apps, APIs, etc.) exist—counting them might be error-prone, so a processor license covers all bases.
Hybrid approach: It’s common for enterprises to mix models across different environments:
- Production might be licensed by the Processor (for unlimited user access),
- Non-production (dev/test/QA) environments by NUP (since only a small team uses them).
This maximizes cost efficiency: e.g., 10 developers each working with personal Oracle instances could be covered by 10 NUP licenses total across those dev systems (assuming they’re on separate small servers, each still meeting minimums), rather than licensing each dev server by processor.
Just ensure that if any dev/test environment has the database accessible by a larger group (say a shared test DB accessed by an app used company-wide for UAT), you count all those UAT users or consider a processor license for that environment.
Cost and Example Scenarios
To solidify the concept, here are a couple of example scenarios comparing costs:
- Scenario 1: Small HR Database
Users: 40 HR staff.
Server: 2 processors (16 cores total, factor 0.5 -> 8 licenses if by proc).- NUP Licensing: Minimum 8 × 25 = 200 Named Users required (because 8 “processors” worth of cores). 200 NUP for 40 actual users means you’re buying 5x more than you need, but Oracle requires 200. Cost = 200 * $950 = $190,000.
- Processor Licensing: 8 Processor licenses required. Cost = 8 * $47,500 = $380,000.
Result: NUP is cheaper here (half the cost of processors)—even though you only have 40 users, you had to pay for 200, but it still beats the processor cost. If the user count were even lower (say 10 users), the NUP cost would remain $190k (still 200 minimum), and the processor cost would still be $380k, so NUP wins for low user counts on this hardware.
- Scenario 2: Customer Portal Database
Users: Undefined (could be thousands of customers).
Server: 4 processors (32 cores, factor 0.5 -> 16 licenses if by proc).- NUP Licensing: Minimum 16 × 25 = 400 Named Users. If you had 1000 customers, you’d need 1000 NUP (above the minimum). The minimum cost = 400 * $950 = $380,000 (if only 400 accounts were active, but likely more). With 1000 users, the cost = 1000 * $950 = $950,000, which is even higher.
- Processor Licensing: 16 Processor licenses. Cost = 16 * $47,500 = $760,000.
Result: For large user counts (e.g., 1000), processor licensing is the way – $760k vs $950k. Even at the bare minimum (400 users), processor licensing was more expensive in this case ($760k vs $380k), but that assumes you truly had only 400 external users. Most likely, a public-facing system has far more, where NUP becomes unmanageably expensive (and possibly non-compliant if user counts fluctuate above licensed amounts). So, the Processor is the practical and safe choice.
These examples show that processors overtake NUP in cost-effectiveness as user counts rise relative to hardware. Also, consider support costs: Oracle charges 22% annual support on the net license price.
So a cheaper licensing route not only saves upfront but also reduces yearly support fees. In Scenario 1, for example, the support on NUP (~$190k licenses) is about $41,800/year vs. $83,600/year for processors on the same system.
Practical Tips for Metric Selection
A few additional tips when navigating NUP vs Processor decisions:
- Future Growth: Always factor in potential 2-3 year growth. A system with 20 users now might have 100 in two years. If you go with NUP now, you must keep buying more as you grow. Sometimes it’s simpler to start with the Processor if growth is inevitable, to avoid incremental purchases and possible shortfalls.
- Mixing in one contract: You can purchase a mix of both license types from Oracle in one agreement. Ensure your license ordering document clearly states how many of each. They will typically be separate line items.
- Conversion / Migration: If you ever need to convert a deployment from NUP to Processor (or vice versa), there’s no formal conversion ratio; you’d purchase new licenses of the other type and possibly terminate the old ones (if not needed elsewhere). Oracle sales might offer some allowance (especially if moving to a higher value, like switching your many NUPs to proc licenses), but plan it as a new purchase.
- Compliance Monitoring: If on NUP, implement monitoring to ensure the number of database accounts (and potential users behind shared accounts) doesn’t exceed your licensed count. For processor licensing, ensure that if you upgrade hardware (add cores, new server, etc.), you also true up licenses accordingly.
- Standard Edition 2 note: SE2’s processor definition is per socket, up to 2 sockets. SE2’s NUP minimum is 10 per server (regardless of cores). Often for SE2, if you truly have a tiny user count (<10), you still must buy 10 NUP – but 10 is a low bar. Example: SE2 on a 2-socket server, min NUP = 10; list cost 10*$350 = $3,500, whereas 2 Processor licenses would be $35,000 (because SE2 is $17,500 per socket). So SE2 environments almost always favor NUP unless user counts are unbounded, because the minimums are low and the cost difference is huge. Many small SE2 deployments opt for NUP.
Recommendations
- Assess User Population First: Before defaulting to one model, evaluate who and what will access the database. If you can confidently count the users/devices and it’s a modest number, lean toward Named User Plus. If it’s a broad or growing audience, go with Processor. Always align the licensing model with the nature of usage (internal vs external, fixed vs variable users).
- Calculate License Costs Both Ways: For each database environment, do the math for NUP and Processor using your current hardware and user count. Include Oracle’s minimums in the calculation. This exercise often makes the cheaper choice obvious. Don’t forget to factor in Oracle’s core factor for processor counts and the 25-per-processor rule for NUP.
- Use NUP for Non-Production Environments: Development, test, and backup environments usually have limited user access (DBAs or developers). Licensing these by Named User Plus can yield significant savings. For example, instead of licensing an 8-core dev server with 4 Processor licenses, you might license it with 10 NUP if only 3 DBAs use it (meeting the 25-per-proc minimum on one processor’s worth of cores, depending on edition). This targeted use of NUP can free up budget for other needs.
- Ensure Compliance with NUP Minimums: If you choose Named User Plus, purchase at least the minimum based on your server’s core count (for Enterprise Edition) or per server (for SE2). Under-purchasing is a compliance risk that Oracle’s audits will catch easily. For instance, don’t assume “we only have five users, so 5 NUP is fine” on an EE server with two processors; you’d need 50 NUP. Always apply the formula.
- Plan for User Growth: If using NUP, periodically re-evaluate your user counts. If an application’s user base jumps, you may need additional NUP licenses to stay compliant. Build this into change management, e.g., when onboarding a new division to an Oracle-based system, include licensing review as a step. It may reach a point where switching to Processor licensing makes sense; be ready to make that call as user count approaches the breakeven point.
- Use Processor for Public-Facing Systems: As a rule of thumb, any system accessible by customers, partners, or the general public should be Processor-licensed. Limiting or counting those users precisely is usually impossible, and trying to do so could lead to severe compliance gaps. The processor model brings peace of mind in these scenarios.
- Keep Documentation of Licensing Basis: Document why you chose NUP or Processor for each system. For example, maintain a record: “System X licensed by NUP–80 NUP licenses purchased, covering up to 80 users; current users = 65.” This helps with internal audits and if Oracle ever questions your counts. For the processor, note the hardware configuration it covers. Remember to update the license needs if that system moves to new hardware.
- Educate Application Owners: Ensure business application owners and architects understand the difference. If they decide to expand an app to more users or consolidate databases onto a bigger server, they need to know it might change the optimal license metric. Early awareness can prevent costly surprises (like discovering an app quietly onboarded 500 more users and blew past your NUP entitlements).
- Leverage Oracle’s Sales for Advice (Cautiously): Oracle reps can provide quotes for NUP and Processor if you ask. Sometimes they nudge one way or another, depending on what they want to sell. Use their input as data, but cross-verify with independent analysis (or use an Oracle licensing expert) to ensure the choice truly benefits your organization, not just Oracle’s sales targets.
- Monitor Multiplexing and Indirect Use: If you license by NUP, be very careful of scenarios where middleware or a pooled connection might hide the true number of end users. Implement monitoring or logs that estimate the unique end users hitting the database through applications. Oracle audits often uncover that what was thought to be 20 users was 200 via a web portal. Set up controls to limit such access or quickly convert to Processor licensing if needed.
FAQ
Q: In simple terms, what is a “Named User Plus” license?
A: A Named User Plus (NUP) license allows one specific individual (or device) to use the Oracle Database. If you have 100 distinct people who use the database, you need 100 NUP licenses (subject to Oracle’s minimum rules). It’s essentially a per-person license rather than per-machine. “Plus” indicates that non-human operated devices (like sensors or batch processes) also count.
Q: What is a Processor license?
A: A Processor license lets you use the Oracle Database on a server with unlimited users. Instead of counting users, you count the CPU cores of the server (adjusted by Oracle’s core factor). You buy a license for each “processor” unit Oracle calculates. It’s a way of licensing the computing power rather than the people.
Q: How do I decide between NUP and Processor for a new Oracle database?
A: Determine how many human (and non-human) users will access the database and what the server’s hardware is. If the user count is low and controlled, calculate the cost for NUP (keeping the 25-per-core minimum in mind). Calculate the cost for the Processor based on the core count. Compare the two. Also, consider future user growth. Generally, use NUP for small internal use cases and Processor for large or external user bases.
Q: What are the minimum Named User Plus licenses required for Oracle Database?
A: For Oracle Enterprise Edition, the minimum is 25 Named User Plus per Oracle-processed core. In practice, multiply the number of processor licenses that would be required (after core factor) by 25 to get the minimum NUP. For Standard Edition 2, it’s simpler: minimum 10 Named Users per server (SE2 doesn’t use core factor, since sockets limit it). Even if fewer people use it, you must buy at least these minimum quantities.
Q: Can I mix Named User Plus and Processor licenses on the same server or cluster?
A: No. A single Oracle Database deployment (e.g., a server or a RAC cluster) must be licensed under one metric, not both. You can’t cover half the users with NUP and half with a processor on the same machine. However, you can license different servers in your environment differently. For example, one standalone dev server by NUP and another standalone prod server by Processor is fine.
Q: Can I switch from NUP to Processor licensing if my user count grows significantly?
A: Yes, you can change your licensing model, but it isn’t an automatic conversion – it usually means purchasing new licenses under the Processor metric and possibly retiring or repurposing the old NUP licenses. Oracle doesn’t have a direct upgrade path from NUP to Processor; you essentially buy processor licenses, and then you might stop using some or all of the NUP licenses (or keep them for another smaller environment if allowed). It’s best to plan ahead to avoid this scenario, as it can be costly to “double up” licenses during a transition.
Q: Do non-human devices or batch processes count as Named Users?
A: Yes. Oracle defines a Named User Plus as any end-point interacting with the database without human operation. For example, if an automated sensor writes data to the database, or if there’s a script that runs cron jobs connecting to the DB, those count. Essentially, each unique connection source that isn’t already a person with a login is counted as a “pseudo-user” for licensing. Oracle wants to prevent the scenario of “we have two users but 10 applications and 500 IoT devices using the DB” from dodging license fees.
Q: How are NUP licenses counted if I have multiple Oracle databases on one server?
A: Named User Plus licensing is generally considered per server (or per Oracle instance environment). If multiple databases run on the same physical server (or same virtualization instance licensed as one environment), you don’t count separate users for each database – you count unique users of any of those databases on that server. Typically, you need a license for each user for each license set. If the databases are set up under one license entitlement on that server, the user just needs to be licensed once to access any of them. Be careful: if you segmented databases for different departments on one server, you still must license the total distinct user count across them. You cannot, for example, buy 50 NUP for one database and a separate 30 NUP for another on the same server if some of those users overlap – you’d need to have at least enough NUP to cover the union of all users (and meet the minimum per processor for the server overall).
Q: What is “multiplexing,” and how does it affect NUP licensing?
A: Multiplexing refers to a scenario where multiple end-users access the database indirectly through a pooling mechanism (like a web server or an application server that funnels all connections through a single login account). Oracle’s rule is to count each end-user, not just the technical connections. So, even if your Oracle database sees only one user account connecting (from the app server), if 100 people are using that app, you need 100 Named User licenses. Multiplexing does not reduce the number of licenses required. It’s a common compliance gotcha – Oracle explicitly disallows using a middle tier to avoid proper licensing.
Q: Is Named User Plus licensing available for Oracle Standard Edition?
A: Yes. Oracle Standard Edition 2 (SE2) can be licensed by Named User Plus or Processor (which for SE2 is per socket). The minimum for SE2 is 10 NUP per server. In practice, many SE2 deployments use NUP because they often have smaller user counts, and the cost is very attractive (SE2 NUP list price is about $350 each, with a 10-user min = $3,500, versus $17,500 for one processor/socket). For a small business application with 5-10 users, NUP on SE2 is a cost-effective choice. Just remember SE2 has its own limitations (max two sockets, 16 threads usage).
Q: Can I reduce costs by using Named User Plus licenses across multiple servers or by splitting them?
A: No, NUP licenses aren’t a floating pool you can spread arbitrarily. They are tied to a specific Oracle deployment or server (technically to the specific Oracle CSI number and product usage on designated machines). You cannot, for instance, buy 100 Named User licenses and use 50 for one database and 50 for another unless those two databases are part of the same license pool on the same environment. Each environment must meet the minimums and have sufficient NUP to cover its users. If an actual person uses two different databases on two different licensed servers, in theory you should have a license for that person on each server (though Oracle’s agreements often allow counting named users within a “license set” covering a defined group of servers, which can get complex – generally each standalone server or cluster is its own case for counting).
Read about our Oracle license management services.
