Oracle SOA Suite's NUP crossover sits at 47.9 users per Processor, but the 10-per-Processor minimum computed off your clustered core count decides the metric before user headcount ever matters
SOA Suite for Oracle Middleware lists at $57,500 per Processor against $1,200 per Named User Plus, a 47.9:1 ratio rather than the clean 50:1 you see on Database Enterprise Edition. That arithmetic only governs single-node estates. Once SOA runs across a load-balanced cluster or a non-partitioned VMware environment, the licensable Processor count drives an NUP floor that can exceed your actual user population by 3x or more, and Processor becomes the cheaper metric by default.
Prepared by Redress Compliance · August 23, 2026 · Oracle middleware advisory. SOA Suite metric and audit engagements 2024 to 2026.
Executive summary
The SOA Suite crossover is 47.9 users per Processor, not the 50 you carried over from Database Enterprise Edition.
At $57,500 per Processor against $1,200 per NUP, SOA Suite for Oracle Middleware breaks even at 47.9 countable users per licensable Processor, while the Non-Oracle Middleware SKU at $75,000 and $1,500 restores the clean 50:1 ratio, so the two SKUs answer the metric question differently.
The NUP minimum is computed off licensable Processors, which means clustering multiplies your floor even if your user count never changes.
Eight licensable Processors at a 10 NUP per Processor minimum force 80 NUP licenses at $96,000 list, so an integration estate with 50 real users pays for 30 phantom ones before anyone logs in.
At least one credible advisory source asserts a 25 NUP per Processor floor for SOA Suite against the majority 10, and the difference reshapes the entire decision.
At 10 the floor costs $12,000 per Processor against $57,500 for Processor licensing; at 25 it costs $30,000 and the NUP case survives only on estates below roughly two Processors.
Support at 22% of net license makes every list-price mistake a recurring annuity, and one advisory source still misprices SOA Suite at $45,000.
That $45,000 figure is WebLogic Suite, not SOA Suite; carrying the wrong anchor into a negotiation costs 22% of the error every year, and each discount point on SOA Suite is worth roughly $2.10 in annual support avoided.
How the two metrics actually compute for SOA Suite
Both metrics start from the same place: a countable Processor number derived from physical cores multiplied by Oracle's core factor (0.5 for most x86 Xeon and EPYC parts, 1.0 for SPARC and IBM Power variants), rounded up to the next whole number per server.
Under the Processor metric you pay that count times list.
Under Named User Plus you pay the greater of your actual countable users or the floor, and the floor is the same licensable Processor count multiplied by the per-Processor minimum, which for Fusion Middleware programs including SOA Suite is 10 NUP per Processor.
Not the 25 that governs Database Enterprise Edition.
One advisory source asserts 25 for SOA specifically.
In 25 years of reading these price lists I have consistently seen 10 applied to middleware, but verify the "Licensing Rules and General Notes" section of the current Technology Global Price List (August 3.
2026 edition) before you sign, because at 25 every crossover below collapses to 4 servers' worth of headroom.
The arithmetic that follows assumes 10.
| SKU (per Processor unless noted) | NUP list | Processor list | Ratio | Crossover users per Processor |
|---|---|---|---|---|
| SOA Suite for Oracle Middleware | $1,200 | $57,500 | 47.9:1 | 47.9 |
| SOA Suite for Non-Oracle Middleware | $1,500 | $75,000 | 50:1 | 50.0 |
| BPEL Process Manager Option | n/a published | $23,000 | n/a | n/a |
| BPEL Process Manager (standalone) | $1,200 | $60,000 | 50:1 | 50.0 |
| Service Bus | n/a published | $23,000 | n/a | n/a |
| Integration Continuous Availability (option) | n/a published | $25,000 | n/a | n/a |
| WebLogic Coherence Grid Edition Option | n/a published | $10,000 | n/a | n/a |
Read the third and fourth rows together. Standalone BPEL Process Manager lists at $60,000 per Processor, $2,500 more than the full SOA Suite for Oracle Middleware that already contains BPEL.
Buyers land on the standalone SKU because a project team asked for "BPEL" by name and the Oracle rep quoted the SKU with that name on it.
There is no scenario in which paying $60,000 for the component beats paying $57,500 for the suite, and the delta compounds at 22 percent support annually, roughly $550 per Processor per year of pure waste.
The $23,000 BPEL Process Manager Option is a different animal: it is an add-on to a base entitlement, not a substitute for the suite.
The second reading is that the 47.9 ratio is an anomaly, not a rule. Oracle's own Non-Oracle Middleware variant of the same product runs a clean 50:1, as does standalone BPEL PM. The Oracle Middleware SKU has drifted to 47.9:1 because the Processor price moved and the NUP price did not.
That two-user gap sounds trivial and is: it shifts the theoretical breakeven by about 4 percent. Do not let a rep frame the metric decision as arithmetic at the margin, because the floor decides it long before the ratio does.
The cluster count: why load balancing rewrites the metric before you count users
Here is the mechanism that catches almost every SOA estate. The NUP floor is not a function of your organization, it is a function of your hardware.
Every server you add to a SOA cluster raises the licensable Processor count, and every Processor you add raises the minimum NUP you must buy, whether or not a single new person logs in.
Take a two-node cluster, each node a single 2-socket server with 20 physical cores at core factor 0.5: that is 10 Processors per node, 20 Processors total, and a floor of 200 NUP.
Scale the same estate to a modest configuration Oracle itself would recommend, 2 Processors per node across two nodes, and the floor is 20 NUP, or $24,000 at list.
Add two more nodes for throughput and high availability and you now hold 8 Processors, a floor of 80 NUP, and a $96,000 list obligation with zero incremental users. Your integration estate did not grow. Your license bill quadrupled.
Three refinements matter when you model this. First, active-active clusters license every node, full stop; there is no discount for a node that handles 15 percent of traffic.
Second, active-passive gives you the failover allowance: a passive node in a properly configured failover cluster may run the program up to ten separate days in any calendar year without a license, provided the nodes share a disk array and only one is active at a time.
That is ten days total, not ten days per event, and Oracle counts a partial day as a full day.
Third, disaster recovery nodes get no such relief once they are running the software; a warm standby with SOA installed and started is licensable, and a cold node with binaries installed but never started generally is not, though you should document the start-stop evidence because LMS will ask.
Virtualization is where the count detonates.
Oracle treats VMware as soft partitioning, which means it does not accept vCPU-based counting: the licensable population is every physical core in every host that the SOA VM could be live-migrated onto, which in a vSphere estate with shared storage means the entire cluster.
And Oracle has argued for the entire vCenter.
A four-host cluster of 2-socket, 24-core servers is 96 cores, 48 Processors after core factor, and a NUP floor of 480 users. If your actual SOA population is 60 developers and operators, Processor licensing is not just cheaper, it is the only defensible metric.
The fix is architectural, not contractual: see our guidance on designing a dedicated Oracle VMware cluster to cap the license count and the wider treatment of where the cluster counts on VMware. Contain first, then choose the metric.
Named User Plus or Processor: The Metric Decision
Oracle sells the same database per user and per processor. The 25 NUP per processor minimum, the 50 user break-even, and how to choose the metric that fits the workload.
Get the white paper →Why the 47.9 crossover is the wrong number to negotiate on
The arithmetic is not in dispute. At $57,500 per Processor and $1,200 per Named User Plus on the SOA Suite for Oracle Middleware SKU, the indifference point falls at 47.9 users per licensable Processor.
That number is correct, defensible against the price list, and almost entirely useless in a real SOA negotiation. It is useless because it assumes you can count the population, and SOA Suite is the one product in the middleware stack where the population is not a room full of people.
It is a message bus. Its consumers are order-entry front ends, EDI trading-partner gateways, batch schedulers, IoT collectors, mobile apps, and other applications' application servers.
Oracle's Named User Plus definition covers individuals and non-human operated devices authorized to use the programs, and on a bus the non-human devices outnumber the humans by an order of magnitude before you have finished the interface inventory.
The multiplexing rule is what closes the trap. Oracle counts users at the point of entry into the multiplexing front end, not at the point where the pooled connection reaches SOA. Pooling, an ESB facade, a portal, or a single service account used by an application tier does not compress the count.
That means the standard architectural argument, "only nine people can log into Enterprise Manager, so we need nine NUP," fails the moment an auditor asks who consumes the composites those nine people administer.
If SOA Suite is orchestrating order-to-cash for an ERP with 4,000 seats, the countable population is not nine. It is 4,000 plus the trading partners plus the devices, and there is no serious reading of the contract that produces a different answer.
That estate was a Processor estate on day one, regardless of what the crossover math says.
Which is why metric selection is, in the overwhelming majority of production SOA deployments we review, a decision that has already been made for you by architecture rather than by commercial preference.
The honest exceptions are narrow and they are bounded by design, not by policy: development and test environments with a named engineering team, single-node departmental integrations that never touch a customer-facing or partner-facing channel, and proofs of concept with a fixed participant list.
Outside those three cases, arguing that NUP applies to a production integration platform is a position you will lose in an audit, and losing it late is expensive because the shortfall is repriced at Processor list with backdated support attached.
The consequence for negotiation strategy is unpleasant but clarifying. Every hour spent arguing metric is an hour not spent on the variable that actually determines the invoice, which is the Processor count itself.
And the Processor count is the number Oracle will happily leave undisturbed while you debate the metric, because the count is computed off the physical cores in every host where the SOA binaries could run.
Multiplied by the Intel core factor of 0.5, with no partitioning credit for VMware clusters that Oracle does not accept as hard partitioning.
A four-host cluster of dual-socket, 32-core servers is 128 processors before core factor and 64 after. At list, that is $3.68 million. No metric argument recovers that. Cluster boundary design does.
See our note on [designing a dedicated Oracle VMware cluster to cap the license count](oracle-dedicated-vmware-cluster-containment-design) for the containment patterns that actually move the number.
There is a second reason the crossover is a distraction: the NUP floor of 10 per Processor (verify this against the Licensing Rules and General Notes in the current price list, because at least one advisory source asserts 25 for SOA.
And the difference is material) means the count is derived from the same Processor figure you were trying to avoid computing.
If your licensable Processor count is 64, your NUP floor is 640 users, or $768,000 at list, and you still had to produce the Processor number to get there. The metric does not release you from the count. It merely reprices it.
So treat 47.9 as a screening test rather than a negotiating position.
Run it once, confirm that your production estate fails it (it will), and redirect the leverage into the three levers that survive contact with an auditor: the physical boundary of the cluster, whether Oracle-approved hard partitioning is in place, and whether the ordering document names the servers.
Buyers who spend their leverage arguing metric are conceding the count, and the count is the whole price.
Where NUP still wins, and how to defend the count
NUP survives where the population is genuinely bounded and the infrastructure is genuinely contained, and both conditions must hold simultaneously.
In practice that means fewer than roughly 48 identifiable users per licensable Processor after the floor of 10 per Processor is applied, deployment on a single node or an Oracle-approved hard partition (Solaris Zones, IBM LPAR, Oracle Linux KVM with pinned CPUs).
And an interface inventory that contains no external consumers, no partner gateways, and no automated device populations feeding the bus.
Development and test estates, departmental single-node integrations, and time-boxed proofs of concept are the recurring winners.
The defense is documentary and you must be able to assemble it in days, not weeks: a directory extract with named accounts and dates, an interface inventory mapping every inbound and outbound endpoint to a consuming system, a multiplexing diagram showing where users enter the chain.
And partition configuration output proving the CPU binding.
Our [Named User Plus counting rules and per-Processor minimums guide](oracle-named-user-plus-counting-minimums-audit-defense) covers the evidence standards auditors accept.
| Condition | What must be true | Evidence to hold on file |
|---|---|---|
| Population bounded | Under 48 countable users per licensable Processor, including devices | Directory extract, interface inventory with consumer mapping |
| Deployment contained | Single node or Oracle-approved hard partition; no VMware cluster spread | Partition configuration output, host inventory, cluster topology |
| No indirect consumers | No partner, customer, or automated feeds through the bus | Multiplexing diagram, endpoint list with authentication model |
| Floor absorbed | 10 NUP per Processor minimum priced in, not exceeded by real headcount | Order document showing quantity and metric per server |
| Contractually fixed | Metric, minimum, and named servers written into the ordering document | Signed OD, plus any partitioning acknowledgment letter |
The row that decides the outcome is the last one. Every other condition is a statement of current fact, and current fact drifts: a test environment gets promoted, a partner feed gets added, a VM gets vMotioned onto an unlicensed host.
The only durable protection is language at order time that names the specific servers or partitions the NUP entitlement covers, states the applicable minimum in figures rather than by reference, and confirms that Oracle has reviewed and accepted the partitioning approach.
The stacking question: WebLogic, Database, and what SOA Suite already includes
The $90,000 per Processor figure you will see quoted for a SOA deployment (SOA Suite at $57,500 plus WebLogic Suite at $45,000, discounted or not) is real arithmetic but usually the wrong bill.
SOA Suite for Oracle Middleware carries a restricted-use WebLogic Server Enterprise Edition entitlement for the Processors on which SOA components actually run.
In practice that means the managed servers hosting BPEL, Mediator, Business Rules, and the SOA infrastructure schema do not need a separate WebLogic license.
And a vendor rep who quotes you both line items for the same cores is either working off a template or testing whether you know the restriction.
Ask for the license grant language in writing and match it to the specific SKU on your ordering document, because the restricted-use grant is a clause, not a courtesy.
Where the restriction genuinely bites is narrower than Oracle's sales motion implies, but it is not empty.
If you deploy non-SOA Java applications into the same WebLogic domain, run standalone WebLogic clusters for custom apps, or use WebLogic Suite features (Coherence, TopLink Grid, WebLogic Suite management packs) beyond what SOA itself consumes.
The restricted-use grant stops covering you and full WebLogic licensing attaches to those Processors.
The clean defense is domain separation: keep the SOA domain SOA-only and put custom applications on separately licensed infrastructure, then document the split before anyone asks.
The Database side is the quieter exposure. The SOA infrastructure schema (MDS, SOAINFRA, and the RCU-created repositories) requires a licensed database, and Oracle does not bundle full Database Enterprise Edition with SOA Suite.
If that repository sits on an existing EE cluster, the SOA workload rides on cores you already license; if it sits on a dedicated instance, price it deliberately. We cover both dependencies in detail on the Oracle integration and SOA licensing buyer guide.
Evidence base and the recurring patterns we see
State the source position honestly. The $57,500 per Processor and $1,200 per Named User Plus figures for SOA Suite for Oracle Middleware are corroborated across the Oracle Technology Global Price List extract and multiple independent advisory sources, and they are the numbers to plan against.
Two items are genuinely in conflict and must be resolved against the current PDF and your own Oracle Master Agreement before you commit a number to a business case.
First, the NUP minimum: the majority position across middleware guidance is 10 per Processor, consistent with WebLogic, WebCenter, and OBIEE, but at least one advisory source asserts 25 for SOA specifically. At 25, the effective floor rises 2.5x and the crossover argument collapses entirely.
Second, the price list effective date: sources cite both April 16 and August 3, 2026. Cite the August 3 edition and re-pull it before any renewal cycle.
$57,500 per Processor divided by $1,200 per NUP, not the clean 50:1 you get on Database Enterprise Edition.
Every list-price point you fail to challenge compounds through the support stream for the life of the estate.
Four patterns recur across engagements. The metric is chosen at proof-of-concept scale, when a two-core sandbox and fifteen developers made NUP obvious, then never revisited after production clustering multiplied the licensable Processor count.
NUP floors are calculated off deployed Processors rather than licensable ones, which understates the floor wherever VMware, DR, or load-balanced nodes are in play; the counting rules in our Named User Plus counting and minimums guide are where those errors surface.
Standalone component SKUs get bought at a premium to the suite, with BPEL Process Manager listing at $60,000 per Processor against $57,500 for the full SOA Suite.
And support renewals quietly compound an unchallenged list-price anchor, at 22% annually, for as long as nobody reopens the original discount.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Pull the August 3, 2026 Technology Global Price List yourself, confirm SOA Suite for Oracle Middleware at $57,500 per Processor and $1,200 NUP, and read the Licensing Rules and General Notes to settle whether your NUP floor is 10 or 25 per Processor, because at least one advisory source asserts 25 for SOA and that single digit moves the breakeven by 2.5x.
- Count licensable Processors before you model either metric, including every cluster member, every passive DR node that is installed and not cold-and-idle, and every host in a non-partitioned VMware cluster, then apply core factors, since our field experience is that this count comes in 2x to 4x above what the architecture diagram implies (see designing a dedicated Oracle VMware cluster to cap the license count).
- Run the 47.9 test against a defensible user definition, counting every human plus every non-human operated device, batch scheduler, partner system, and B2B endpoint that submits work to SOA, then compare that total against 10 (or 25) times your licensable Processor count, using the Named User Plus counting rules and per-processor minimums as the authority for what counts.
- Audit your entitlements for standalone component SKUs, because standalone BPEL Process Manager lists at $60,000 per Processor against $57,500 for the full suite, and Service Bus plus BPEL PM bought separately at $23,000 each can be the wrong shape once you need three or more components.
- Price the 22% support stream before you concede anything on discount structure, since every dollar of net license carries roughly $2.10 in support over ten years, and a deeper discount on the wrong metric simply locks a smaller mistake in for a decade.
Frequently asked questions
What is the list price of Oracle SOA Suite per Processor?
SOA Suite for Oracle Middleware lists at $57,500 per Processor with Named User Plus at $1,200 per user. The separate SOA Suite for Non-Oracle Middleware SKU lists at $75,000 per Processor and $1,500 NUP.
Verify both against the current Oracle Technology Global Price List PDF, because at least one advisory source incorrectly quotes SOA Suite at $45,000, which is actually the WebLogic Suite price.
At how many users does Processor licensing beat NUP for SOA Suite?
Dividing $57,500 by $1,200 gives 47.9 users per licensable Processor as the arithmetic crossover. Above roughly 48 countable users per Processor, Processor licensing is cheaper.
Note this differs from Database Enterprise Edition, where the ratio is exactly 50:1 ($47,500 against $950), so do not carry the Database rule of thumb across.
Is the SOA Suite NUP minimum 10 or 25 per Processor?
The majority advisory position is 10 NUP per Processor for Oracle Fusion Middleware products including SOA Suite, WebLogic Server, and WebCenter, against 25 for Database Enterprise Edition. At least one source asserts 25 specifically for SOA Suite.
The difference is material (a 4-Processor estate needs either 40 or 100 NUP), so confirm the figure in the Application Specific Licensing Rules and General Notes section of the current price list before you model anything.
How does clustering change SOA Suite licensing costs?
Every node in an active-active or load-balanced cluster is licensable, so a two-node cluster doubles the Processor count and doubles the NUP floor derived from it. A four-Processor estate at a 10 NUP minimum requires 40 NUP licenses even with 15 real users.
This is why NUP frequently fails on clustered SOA deployments regardless of user headcount.
Does SOA Suite include a WebLogic Server license?
SOA Suite carries restricted-use WebLogic entitlement for the Processors running SOA components, which means the frequently quoted $90,000 per Processor stack (SOA Suite plus WebLogic Suite) is often avoidable.
The restriction bites when non-SOA applications are deployed to the same domain or when you run standalone WebLogic clusters. Confirm the restricted-use scope in your ordering document, not in a datasheet.
Do automated systems and interfaces count as Named Users for SOA Suite?
Yes. Oracle's Named User Plus definition includes non-human operated devices, and the multiplexing rule states that front-end pooling, middleware, or application servers do not reduce the number of users requiring licenses.
For an integration bus feeding a large ERP or portal, the countable population is effectively the downstream user base, which is why NUP rarely survives on production SOA estates.
How much does Oracle SOA Suite support cost each year?
Premier Support runs at 22% of the net license fee annually and is subject to uplift at renewal. On a single Processor license at list, that is $12,650 per year against a $57,500 one-time fee.
Each discount point you win on SOA Suite is worth roughly $2.10 in annual support avoided, so model the support stream over the contract term before trading discount for scope.
