The NUP metric prices the named human and non-human users that access an Oracle deployment, subject to a per-processor minimum that frequently re-anchors the licence count. The Admodum read on when NUP pays and when the processor metric wins.
The Named User Plus metric prices the count of named users authorised to access (directly or indirectly) an Oracle deployment. The count includes human users and non-human operated devices (sensors, applications running as batch). The metric reads against the contracted entitlement at the date of audit.
The mechanics are direct. A buyer running an Oracle Database EE deployment under NUP must count every named user authorised against the database. Each user counted requires one NUP licence. The count includes the human user population, the named non-human users and, under the multiplexing rule, any user whose access is mediated by an application server, web server or middleware layer.
The wider processor-metric article sets out the alternative metric. The two metrics together cover the principal Oracle Database EE commercial constructions.
The NUP metric carries a per-processor minimum. The minimum reads as the licensable processor count multiplied by the published minimum NUP per processor for the named edition. For Oracle Database Enterprise Edition, the minimum is typically 25 Named User Plus per processor.
The minimum re-anchors the licence count when the actual user count sits below the floor. A deployment running on four processor licences under NUP cannot license fewer than one hundred NUP (4 processors × 25 NUP/processor). The buyer counting only sixty actual users still pays for the minimum one hundred.
The procurement implication is that the NUP metric is commercially attractive only where the user count materially exceeds the per-processor minimum. A small deployment with eighty users on four processors pays the same under NUP as under the processor metric (sixty actual NUP licences are bought up to the one hundred minimum, which then reads against four processor licences at the same per-licence rate).
The multiplexing rule reads that a user accessing the database through an intermediary layer (application server, web server, middleware, ESB) counts as a named user under the metric. The rule prevents the buyer from reducing the NUP count by inserting an architectural layer between the user population and the database.
The rule applies regardless of the intermediary technology. A Java application server pooling a small number of database connections does not reduce the NUP count to the connection count; the count reads against the user population behind the application server. The same logic applies to web tier deployments, to messaging-based access patterns and to API gateways fronting the database.
The procurement implication is that NUP is unsuitable for Internet-facing deployments. A consumer-facing application running on Oracle Database EE under NUP would require a named-user entitlement for every consumer; the population is functionally unlimited, so the NUP construct does not commercially apply. The deployment reads against the processor metric (or, in some constructions, the application-specific metric).
The NUP metric counts non-human users where they access the database. The non-human count includes named applications running as scheduled batch processes, named devices (sensors, point-of-sale terminals, ATMs) and named integration accounts (ETL jobs, replication processes, system-to-system service accounts).
The publisher reading on non-human counts is typically expansive: every named application, every named device, every named system account counts as a non-human user. The buyer-side reading runs against the specific contractual language and the publisher’s general definitions. The two readings often diverge on which non-human accesses count and which do not.
The Admodum methodology audits the non-human user surface as part of the wider NUP reconciliation. The audit produces the defensible non-human user count that enters the renewal posture and the audit response. The wider methodology sits in the LMS Audit Defence paper.
NUP is the buyer’s friend in small, contained, internal deployments where the user count is well below the per-processor minimum implied by the processor licence count. A four-core Standard Edition 2 deployment running an internal departmental application with twenty named users may sit below the per-processor minimum for SE2 and read against a small NUP licence count at a meaningful discount to the processor-metric position.
NUP is not the buyer’s friend in any of the following: Internet-facing deployments (the multiplexing rule expands the count to the consumer population); large enterprise deployments (the per-processor minimum re-anchors the count to the processor licence count); deployments with a substantial non-human user surface (the publisher reading expands the count materially).
The decision sits inside the wider Oracle commercial picture. The Admodum methodology produces the per-deployment metric recommendation as part of the licence-portfolio audit. The recommendation reads NUP against processor against the application-specific metrics and selects the metric that pays the lowest defensible position.
The buyer holds three positions against NUP. The first is the actual user count (human plus non-human) reconciled against the contracted entitlement. The second is the per-processor minimum reading against the licensable processor count. The third is the multiplexing posture, recorded in the audit-quality inventory and defended in the audit response.
Where the three positions align with the contractual entitlement, NUP is the right metric and the renewal posture protects the position. Where they diverge, NUP is the wrong metric for the deployment and the renewal repackages the licences against the processor metric.
The wider editorial context sits in the Oracle licensing pillar. The engagement entry point sits in the Oracle practice. Continuous metric coverage sits inside the annual retainer.
How the alternative metric reads against the deployed estate.
The named feature list that elevates a deployment from SE2 to EE.
A senior Admodum Oracle advisor will reconcile your NUP count, the per-processor minima and the multiplexing posture on a private call. Active audits route to the Audit Defence programme.