Oracle counts Named Users at the front end where data enters, not at the handful of pooled connections your database actually sees. This is the single most common NUP under-count in audits, and here is how to size it before Oracle's auditors do it for you.
Oracle counts Named Users at the front end where data enters, not at the handful of pooled connections your database actually sees. This is the single most common NUP under-count in audits, and here is how to size it before Oracle's auditors do it for you.
Oracle's Named User Plus (NUP) definition contains a clause that undoes most of the savings companies think they are getting from application servers and connection pools. The License Definitions and Rules state: "If multiplexing hardware or software (e.g., a TP monitor or a web server product) is used, this number must be measured at the multiplexing front end." In plain terms, if 100 employees reach an Oracle database through a single shared application login, all 100 must be licensed, not the one pooled account the database sees.
In 25 years of negotiating Oracle Database agreements, this is the clause I see misread more than any other. The technical architecture that makes your system scale (pooling many sessions over few physical connections) is precisely the architecture that hides your true licensable population from your own SAM tooling. Your database shows a tiny count. Oracle's License Management Services auditors count the humans behind the middle tier. The gap between those two numbers is the audit finding.
This page explains the mechanism, the one narrow exception (batching), how service accounts and devices stack on top, and the sizing math you should run before renewal. If you have not already, read the pillar on NUP counting rules and audit traps for the full metric context.
The technical cause is straightforward. A modern application server or transaction monitor maintains a pool of connections shared by all users. From the database's perspective, only a small number of sessions are logged in at any moment, often a single service identifier such as app_user. Oracle's own JDBC documentation describes how a high-end application server multiplexes several sessions over fewer physical connections on a call-level basis, pooling connections and back-end server processes for scalability.
That efficiency is real, and Oracle does not object to it. What Oracle objects to is licensing off the pooled figure. A documented example: a test database with a single licensed Named User showed 26 database accounts, one of which (app_user) was an application-server identity allowing 250 named users to connect as one. In Oracle's terminology that application server is a "multiplexing front-end," and the 250 must be licensed, not the one.
Your database sees the pool. Oracle counts the people. The delta is the finding, and it is almost always retroactive.
This is why extracting DBA_USERS and calling it a Named User list is the fastest route to an under-declaration. The database dictionary cannot see through the middle tier. A defensible count starts at the application's own authentication layer, HR systems, and identity provider, then reconciles down. We cover the reconciliation auditors accept in the guide to building a defensible named user list.
There is exactly one narrow exception to front-end counting, and buyers routinely stretch it past breaking. Oracle's License Definitions and Rules permit "automated batching of data from computer to computer." This means a scheduled, machine-to-machine data transfer with no human in the loop does not drag the source system's user population into the target system's count.
The classic application: if data is stored in one relational database and then batched to a data warehouse running on Oracle, the individuals who use the first database are not treated as Named Users of the warehouse. Historically, such batch loads ran through a program with no user intervention and were treated as a single "non-human operated device," that is, one Named User, not the whole upstream population.
Do not build a licensing position on a broad reading of batching. In audit defense, the exception protects genuine ETL and warehouse pipelines. It does not protect a portal or an integration bus that fields user requests.
Front-end counting does not replace device counting; it adds to it. Oracle's NUP definition states that a non-human operated device is counted as a NUP in addition to all individuals if such devices can access the programs. Scanners, sensors, IoT endpoints, bots, and service accounts are Named User Plus licenses in their own right.
There is no floating or concurrent concept anywhere in the NUP model to soften this. Licenses cannot be shared or dynamically allocated based on usage; each unique human or device that is authorized to access the software requires its own license, regardless of whether it is actively using the program at that moment. NUP is about authorization, not activity. For the full treatment of automated and device counting, see counting non-human named users: batch jobs, sensors, and automated devices.
The practical trap: an architecture that hides users behind a pool often also runs dozens of service accounts, integration identities, and automated feeds. Each of those is a candidate NUP. The clean-room approach is to inventory every distinct authenticated identity, human or machine, that can reach the schema, then apply the batching exception only where you can prove no human intervention.
Once you accept that the front-end population counts in full, the sizing question becomes mechanical. You always license the higher of the per-processor minimum floor and your real, front-end headcount. On Enterprise Edition the floor is 25 NUP per Processor license the hardware requires; on Standard Edition 2 it is 10 NUP per server. Full worked examples are in the 25 NUP-per-processor minimum guide.
| Metric / floor | Enterprise Edition | Standard Edition 2 |
|---|---|---|
| NUP list price (each) | $950 | Included in SE2 metric structure |
| Processor list price | $47,500 | N/A (per-socket, SE2) |
| Minimum NUP floor | 25 per Processor | 10 per server |
| Support (Premier) | 22% of net license fee/yr | 22% of net license fee/yr |
| NUP break-even vs Processor | ~50 real users per Processor | See SE2 socket rules |
Two figures on the current Technology Global Price List (effective 16 April 2026) drive the whole calculation: Enterprise Edition at $47,500 per Processor and $950 per Named User Plus. Note the ratio. NUP is priced at exactly one fiftieth of the Processor price. That is not a coincidence; it is Oracle's engineered break-even. The Processor metric wins the moment you pass 50 real users per Processor.
The crossover is arithmetic, not judgment: past 50 real users per processor, Processor licensing is cheaper, and the multiplexing rule keeps pushing the front-end count upward.
This is where multiplexing bites hardest. The hidden front-end population, the users your database never sees, can silently push you past the crossover point. If you licensed NUP believing you had 30 users, and the front-end reveals 400, you have not only under-declared, you have chosen the wrong metric entirely. Work the crossover before you commit; the NUP-to-Processor crossover analysis shows how to run it.
Take a server with two Intel Xeon processors, each with 8 cores (16 cores total), at the standard x86 core factor of 0.5. That requires 8 Processor licenses. On Enterprise Edition the NUP minimum is 8 x 25 = 200 NUP, even if you can count only 50 actual users. The floor sets a hard basement. If your true front-end population turns out to be 900 users, you license 900 (well past crossover, at which point you should be evaluating 8 Processor licenses instead). To count the processors correctly in the first place, use the Oracle Core Factor Table.
NUP is not permitted for any environment where users cannot be counted. That includes public web portals, multi-tenant SaaS front ends, and any third-party application where the user population is not knowable to the licensee. Internet-facing applications built on Oracle Database create an open-ended obligation that Oracle's audit methodology investigates rigorously, precisely because the front-end population is theoretically unbounded.
If you have deployed NUP against a customer-facing portal or a B2B integration platform, treat that as a red-flag exposure now, not at audit time. Oracle's expectation on such systems is the Processor metric, which carries no headcount. See why Oracle won't let you use Named User Plus on internet-facing systems for the argument Oracle will make and the position you should hold.
A final trap that compounds multiplexing exposure: database options and management packs must be licensed on the same metric and at least the same quantity as the underlying database. If your database is licensed at 400 NUP because of the front-end population, your Partitioning, RAC, Advanced Security, and any Diagnostics or Tuning packs cannot be licensed at a lower NUP count. The options stack on the corrected number, not the pooled one.
With Partitioning at $11,500 per Processor, RAC at $23,000 per Processor, and Multitenant adding further, an under-declared user base multiplies the shortfall across every option in the stack. See why your Partitioning NUP can't be lower than your database NUP. This is why independent reviews routinely find 25 to 45 percent of total Oracle spend driven by misapplied metric rules rather than by list price or discount.
The buyer-side playbook here is about getting ahead of the count while you still control the narrative. Once Oracle LMS opens an audit and finds, say, 150 unlicensed users reaching data through a web service, they typically demand licenses for each, often retroactively, and at a weakened negotiating position. Do the work first:
The through-line is simple. Multiplexing does not reduce anything; it only hides the count from your own tooling. Size it correctly, choose the right metric, and the front-end rule becomes a known quantity rather than a six- or seven-figure audit surprise.
No. Oracle's multiplexing rule requires the count to be measured at the front end where users enter data, not at the pooled connections the database sees. If 100 people access the database through one shared application login, all 100 must be licensed. Pooling improves scalability but has no effect on your licensable population.
Oracle permits automated, computer-to-computer batching of data without triggering front-end user counting. For example, data batched from an application database into an Oracle data warehouse does not drag the source system's users into the warehouse count. The exception is narrow: it applies only to fully automated transfers with no human intervention, and it never covers interactive middleware such as web servers or application servers serving live user sessions.
Yes, and they stack on top of the human count. Oracle's NUP definition explicitly includes non-human operated devices, so scanners, sensors, bots, and service accounts each count as a Named User Plus in their own right, in addition to all individuals who can access the programs. There is no floating or concurrent concept to soften this.
NUP is priced at exactly one fiftieth of the Processor price on Enterprise Edition ($950 versus $47,500), so the Processor metric wins the moment you pass roughly 50 real users per Processor. Because the multiplexing rule counts the full front-end population, hidden users behind an application server can push you past that crossover without you realizing it. Run the crossover math against your corrected headcount before renewal.
No. NUP is unavailable for any environment where the user population cannot be counted, including public portals, multi-tenant SaaS, and third-party applications with unknown users. Oracle's audit methodology targets internet-facing NUP because it creates an open-ended obligation. Use the Processor metric for these systems.
Do not extract the count from the database dictionary, because it only sees the pool. Count from the application's authentication layer, the identity provider, and HR systems, then reconcile downward. Inventory every service account and device separately, apply the batching exception only where you can document it, and keep the evidence so you enter any audit with your own reconciled number.
Oracle licenses cores times a core factor, not raw cores. The 0.5 x86 factor, the worked counting, the virtualization trap, and where the factor does not apply.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
