Short answer: PeopleSoft database licensing requires a separate Oracle Database license — Enterprise Edition or Standard Edition 2 — beneath the PeopleSoft application, licensed by Processor or Named User Plus. The application license never includes it, and the database layer is where most PeopleSoft audit exposure is created.
Key Takeaways
- The Oracle Database under PeopleSoft is a separately licensed product — your PeopleSoft application licenses do not cover it, and it must be licensed by Processor or Named User Plus in its own right.
- Processor licensing counts physical cores times the Core Factor; Named User Plus carries a 25 NUP per processor minimum — for a database serving thousands of self-service employees, Processor is almost always required.
- Application-Specific Full Use (ASFU) database licenses are cheaper but may only run PeopleSoft; running any other workload breaches the terms and requires Full Use licensing.
- Diagnostics Pack, Tuning Pack, Partitioning, and Advanced Security are separately licensed options — accidental Diagnostics Pack use appears in 40%+ of enterprise Oracle environments (Oracle Licensing Experts, 2026).
- The database layer, not the PeopleSoft application, is where the largest back-license claims originate — virtualization and options are the two most common traps.
Does PeopleSoft require a separate Oracle Database license?
Yes — and this is the misunderstanding that drives most PeopleSoft database compliance gaps. PeopleSoft is an application that stores its data in a relational database, and on the overwhelming majority of installations that database is Oracle Database. Your PeopleSoft application licenses — Named User Plus, Employee metric, or Application User — grant the right to run the PeopleSoft software. They do not grant the right to run the Oracle Database engine that sits beneath it. That database is a distinct Oracle product with its own price list, its own metrics, and its own audit exposure.
The Oracle Database underneath PeopleSoft comes in two editions that matter here. Database Enterprise Edition (EE) is the full-feature engine that most PeopleSoft production environments run, licensed by Processor or Named User Plus. Standard Edition 2 (SE2) is the lower-cost, capacity-limited engine usable only on servers up to a defined socket limit. Choosing the wrong edition — or assuming the application deal bundled the database — is exactly the kind of gap Oracle's audit is built to surface. For the full product map, see the PeopleSoft Licensing Guide and the broader Oracle Database Licensing Guide.
Is PeopleSoft Oracle Database licensed by Processor or Named User Plus?
Short answer: Either. Processor licensing counts physical cores times the Core Factor and suits large or external populations. Named User Plus counts authorized users with a 25 NUP per processor minimum and suits small, countable populations. PeopleSoft self-service usually forces Processor.
The Processor metric licenses the database by the hardware it runs on: count the physical cores in the server, multiply by the Oracle Core Factor for that processor type (0.5 for most x86 chips), and license the result. Processor licensing places no limit on the number of users, which is why it fits PeopleSoft deployments where the user population is large, uncountable, or external — and a PeopleSoft HCM database serving the entire workforce through self-service is exactly that case.
Named User Plus licenses the database by authorized individuals instead, but with a hard floor: a minimum of 25 Named User Plus per processor for Enterprise Edition. For a small, fully countable population — a back-office PeopleSoft Financials database used by a finance team of forty — NUP can be far cheaper than Processor. The mistake we see most is mixing the two assumptions: customers buy NUP database licenses sized to their finance users, then expose the same database to thousands of self-service HCM employees, blowing through the count. Model both metrics against the real population before you commit; the mechanics carry over directly from PeopleSoft User Licensing: Named vs Concurrent.
| Scenario | Database population | Lower-cost metric | Why |
|---|---|---|---|
| HCM with self-service | Whole workforce | Processor | NUP count uncountable / too high |
| Financials, finance team only | ~40 named users | Named User Plus | Small, countable population |
| External / partner access | Unknown / public | Processor | Cannot count external users |
| Dev / test, few DBAs | Handful of users | Named User Plus (25/proc min) | Minimum floor still applies |
Our License Optimization service reconciles your database edition, options, and metric against your real PeopleSoft deployment before Oracle's LMS scripts do. See the healthcare case study: $6M of audit risk eliminated.
What is an ASFU PeopleSoft database license and where is the trap?
Short answer: An Application-Specific Full Use (ASFU) license is a restricted Oracle Database license sold cheaply with PeopleSoft, usable only to run PeopleSoft. Run any other workload on that database and you breach the ASFU terms, requiring a Full Use license.
Oracle sells two kinds of database license that can sit under PeopleSoft. A Full Use (FU) license is the standard, unrestricted Oracle Database license you can use for any application. An Application-Specific Full Use (ASFU) license is sold bundled with the PeopleSoft application at a discounted price, on the condition that the database is used solely to run that PeopleSoft application — nothing else.
The ASFU trap is workload creep. A DBA adds a custom reporting schema, an integration job, a data warehouse extract, or a second non-PeopleSoft application onto the same database instance. Each of those uses breaches the ASFU restriction and converts the requirement to Full Use licensing — usually discovered for the first time in an audit, priced retroactively. If you hold ASFU database licenses under PeopleSoft, treat the instance as ring-fenced: nothing but PeopleSoft runs on it, ever, without first checking the entitlement. This is contractual ground worth defending, and it is exactly the kind of detail Oracle's sales motion relies on customers overlooking.
Which Oracle Database options trap PeopleSoft customers in an audit?
Oracle Database options and management packs are separately licensed add-ons that are trivially easy to enable and expensive to license. The four that catch PeopleSoft customers most often are Diagnostics Pack and Tuning Pack (the performance management packs that ship enabled and that DBAs use through Enterprise Manager and AWR reports), Partitioning (frequently switched on to manage large PeopleSoft tables), and Advanced Security (transparent data encryption for HR and payroll data). Each is licensed by the same Processor or NUP metric as the database itself, multiplying the cost.
The reason these are audit gold is that they self-activate. Diagnostics Pack functionality is enabled by default on Enterprise Edition, and merely running a standard AWR report counts as usage that Oracle's scripts detect. Across enterprise Oracle environments, accidental Diagnostics Pack usage appears in more than 40% of estates. Before any audit, run the option-usage checks yourself, disable management packs you do not license through the CONTROL_MANAGEMENT_PACK_ACCESS parameter, and confirm Partitioning and Advanced Security are not silently in use. Finding this first — rather than letting LMS find it — is the difference between a configuration change and a seven-figure back-license claim. The full options exposure picture sits in the Oracle Database Licensing Guide.
How does virtualization affect PeopleSoft database licensing?
Virtualization is the single biggest Oracle compliance trap, and it applies squarely to PeopleSoft database environments. Oracle's position is that for soft partitioning technologies — most notably VMware — you must license every physical core in every server across which the virtual machine could possibly run, not merely the cores allocated to it. In a clustered VMware environment with vMotion enabled, Oracle argues that scope extends to the entire cluster, and in some readings every cluster the storage connects to.
For a PeopleSoft database running on a few virtual CPUs inside a large VMware farm, that interpretation can multiply the licensable processor count many times over. Oracle's view is a policy position, not a contractual term, and it is contestable — but you contest it with architecture evidence and host-affinity controls, not after the audit notice arrives. Pin PeopleSoft database VMs to defined hosts, document the boundary, and keep the configuration evidence. For the full virtualization defense, see the Oracle Audit Defense Guide and our Audit Defense service.
How do you right-size PeopleSoft database licensing before renewal?
Right-sizing the database layer follows a consistent forensic sequence. Inventory every Oracle Database instance running PeopleSoft and confirm its edition, metric, and whether the licenses are Full Use or ASFU. Run the option and management-pack usage checks and disable anything you do not license. Map the processor count under your actual virtualization architecture and pin VMs to bound the scope. Reconcile the user population against your NUP entitlements and the 25-per-processor floor. Only then take the evidence into the renewal.
The savings here are often larger than on the application itself, because database options and virtualization scope compound. Consolidating PeopleSoft databases onto bounded hosts, dropping unlicensed options, and converting an over-scoped NUP estate to right-sized Processor licensing routinely removes seven figures of exposure. To attack the resulting 22% support stream, pair this with PeopleSoft Third-Party Support and our Contract Negotiation service. And if a database consolidation or edition change is on the table, model it against headcount-driven application cost in PeopleSoft HCM Licensing & Employee Metrics first.
PeopleSoft Database Licensing FAQ
Does PeopleSoft require a separate Oracle Database license?
Yes. PeopleSoft application licenses do not include the Oracle Database underneath. The database is a separately licensed product — Enterprise Edition or Standard Edition 2 — and must be licensed in its own right by Processor or Named User Plus. Many PeopleSoft customers discover in an audit that their database layer was never properly licensed.
Is PeopleSoft Oracle Database licensed by Processor or Named User Plus?
Either, depending on the deployment. Processor licensing counts physical cores times the Core Factor and suits large or external user populations. Named User Plus counts authorized users with a 25 NUP per processor minimum and suits small, countable populations. For a PeopleSoft database serving thousands of self-service employees, Processor licensing is almost always required.
What is the Application-Specific Full Use (ASFU) PeopleSoft database license?
An ASFU license is a restricted-use Oracle Database license sold with the PeopleSoft application at a lower price, usable only to run that application. It cannot be used for custom schemas or other workloads. If you run anything beyond PeopleSoft on that database, you breach the ASFU terms and need a Full Use license instead.
Do PeopleSoft database options like Diagnostics Pack need licensing?
Yes, and they are a leading audit trap. Diagnostics Pack, Tuning Pack, Partitioning, and Advanced Security are separately licensed options that are often enabled by default or by a DBA without a license. Oracle's LMS scripts detect option usage, and accidental Diagnostics Pack use alone appears in 40%+ of enterprise Oracle environments.
How does Oracle audit PeopleSoft database licensing?
Oracle LMS scripts query the database for installed edition, enabled options and management packs, processor and core counts, and feature usage history. They compare that against your entitlements and your PeopleSoft user population. The database layer — not the application — is frequently where the largest PeopleSoft back-license claims originate.
Can I run PeopleSoft on Standard Edition 2 to cut database cost?
Sometimes. SE2 is far cheaper but is limited to servers up to a defined socket count and lacks options like Partitioning and many performance packs. For smaller PeopleSoft Financials or HR deployments it can be viable; for large HCM estates needing Enterprise features it is not. Validate the feature dependencies before assuming SE2 fits.
Close the PeopleSoft database gap before Oracle finds it
We reconcile your database edition, metric, options, and virtualization scope against your real PeopleSoft estate and build the evidence to defend it — independent, buyer-side, and built on 600+ engagements.