Oracle Named User Plus: The Licensing Model That Penalises Efficient User Management

Oracle Named User Plus (NUP) licensing is Oracle's per-user licensing metric, available as an alternative to processor-based licensing for Oracle Database and many Oracle applications. On the surface, NUP appears straightforward: license the users who access the Oracle software, not the server hardware. In practice, NUP licensing contains minimum requirements, counting rules, and audit exposure areas that make it substantially more complex — and frequently more expensive — than it initially appears. The two most consequential NUP rules are the minimum NUP per processor requirement (which establishes a floor that can make NUP more expensive than processor licensing for lightly-staffed environments) and the counting methodology (which counts all users who could access Oracle, not just those who actively do). This guide explains both rules in full, when NUP is commercially preferable to processor licensing, how to reduce NUP counts legally, and the common NUP positions that create Oracle audit exposure. For processor-based licensing context, see our Oracle Processor Factor Table Guide. For NUP licence position review, our Oracle advisory team provides independent Oracle licensing assessments.

How Oracle Counts Named User Plus

Oracle's NUP definition: a Named User Plus is an individual authorised to use the programs, which are installed on a single server or multiple servers, regardless of whether the individual is actively using the programs at any given time. The key phrase is "authorised to use" — not "actively using." An employee who has been granted access to an Oracle application or database, but who has not logged in for 12 months, is still a Named User Plus unless their access has been formally revoked.

The full scope of who must be counted as a Named User Plus:

All human users with access. Every employee, contractor, partner, or external party who has been granted authorisation to access the Oracle software — including read-only access — must be counted. Access means having a database account, an application login, or any other mechanism that permits them to query or interact with Oracle-managed data.

Automated processes with dedicated accounts. Batch jobs, ETL processes, APIs, and integration middleware that connect to Oracle using dedicated user accounts (rather than a generic service account) must be counted as Named User Plus licenses. An ETL tool that creates individual user-named database connections rather than a pooled application connection requires NUP licenses for each named account.

The "worst case" count at any point in time. Oracle counts NUP at the high-water mark — the maximum number of authorised users at any point during the license period, not the current count. If an organisation had 500 NUP-eligible users in January and reduced to 300 by December, Oracle's audit position is 500.

The Minimum NUP Per Processor Rule

Oracle Database licensing contains a minimum NUP per processor requirement. For Oracle Database Enterprise Edition, the minimum is 25 NUP per processor license that would otherwise be required. For Oracle Database Standard Edition 2, the minimum is 10 NUP per socket. This minimum exists to prevent organisations from buying NUP licenses for a small number of users on a large server as a way of avoiding the full processor license cost.

Oracle ProductMinimum NUP per Processor / SocketNUP List PriceProcessor License List PriceBreak-even (approx.)
Oracle Database EE25 NUP per processor license$950/NUP$47,500/processorExactly 25 users (minimum = break-even)
Oracle Database SE210 NUP per socket$350/NUP$17,500/socketExactly 50 users per 2-socket server
Oracle Database Standard Edition 2 (per socket cap)10 NUP per socket (max 2 sockets)$350/NUP$17,500/socket>50 users = processor socket cheaper

When NUP beats processor licensing: NUP is commercially preferable to processor licensing when the number of authorised users is below the minimum NUP threshold — which means NUP is never preferable on a per-processor basis (because the minimum enforces at least processor-equivalent cost). The NUP model becomes genuinely advantageous when a small number of users access Oracle on a large server. Example: a 2-socket, 32-core Intel server (16 Oracle EE processor licenses required at 0.5 factor) running Oracle EE for 30 identified users. Processor licensing = 16 × $47,500 = $760,000. NUP licensing = max(30 actual users, 16 processors × 25 minimum) = max(30, 400) = 400 NUP × $950 = $380,000. In this case NUP is actually more expensive because the minimum NUP rule dominates. NUP only beats processor when users × $950 < processor count × $47,500 — and the minimum rule ensures this only occurs when actual user count is the binding constraint, not the minimum.

Reducing NUP Counts: What Works and What Doesn't

Legal NUP count reduction requires removing access authorisation — not just inactivity. The mechanisms that genuinely reduce NUP counts:

User access reviews and deprovisioning. A formal process of identifying and revoking access for users who no longer require it — leavers, role changes, project completions — reduces the authorised user count. Oracle's audit position is the maximum authorised count; consistent deprovisioning keeps that maximum lower. A quarterly access review process that removes dormant accounts within 90 days of last access is a defensible deprovisioning practice.

Application connection pooling. Many Oracle application tiers (Java EE, Oracle Forms, Oracle APEX) connect to Oracle Database via a connection pool — a single set of service accounts shared across all application users. If the application authenticates its own users and connects to Oracle through pooled service accounts, the Oracle NUP count is the number of service accounts in the pool, not the number of application end users. This is Oracle-recognised and, when properly configured, dramatically reduces NUP exposure for large user populations accessing Oracle through application tiers.

Switching to processor licensing for large user populations. When user counts grow beyond the minimum NUP threshold — typically beyond 50–75 users per processor — processor licensing typically becomes cost-effective compared to NUP. The NUP-to-processor conversion should be modelled annually as user counts change.

What does not reduce NUP counts: limiting login frequency, disabling inactive accounts without deprovisioning Oracle access, or providing users read-only access (read-only access still requires NUP). For NUP licence position review and Oracle audit preparation, our Oracle advisory team assesses your current NUP position and identifies the optimisation path. Book a licence position review with our team.

Get an Oracle NUP Licence Position Review

Our Oracle advisory team reviews your Oracle Database NUP counts against Oracle's counting methodology, models NUP vs processor licensing economics at your current and projected user counts, identifies deprovisioning and connection pooling opportunities to reduce NUP exposure, and prepares your position for Oracle audit.

Book an Oracle Licence Position Review →