Oracle Database Licensing Guide

Oracle Database Licensing Guide

Managing Oracle Database licenses can be complex. Procurement and IT leaders must understand product editions, metrics, and restrictions.

This guide reviews Standard Edition 2 (SE2), Enterprise Edition (EE), and other editions. It explains licensing models—Processor vs. Named User Plus (NUP)—and cloud options (Oracle Cloud, AWS/Azure BYOL, Cloud@Customer).

Key concepts are core factor, minimum user counts, virtualization (hard vs soft partitioning), RAC, and options/add-ons.

We use tables, examples, and real scenarios. Citations point to Oracle’s official policies and expert analyses.

Editions and Features

Oracle offers multiple Database editions. Standard Edition 2 (SE2) is for smaller deployments; Enterprise Edition (EE) is full-featured for high-volume workloads. Personal and legacy editions exist but are niche.

• SE2: It is limited to servers with two sockets max. It includes core database capabilities (OLTP, basic security) “necessary to develop workgroup, department-level, and Web applications.” SE2 cannot use many enterprise options (no parallel option, limited RAC, etc.).
• EE: No hard socket limit. It “provides performance, availability, scalability, and security for high-volume OLTP, data warehouses, and demanding Internet apps”. EE can be enhanced with many paid options and packs (RAC, Partitioning, In-Memory, etc.).
• Personal Edition (PE): Single-user license for development. It “includes all components of EE” except RAC and RAC One Node. PE cannot be used in production and excludes some management packs.

Read Oracle Database Licensing: A Guide for IT Leaders.

Licensing Metrics

Oracle Database can be licensed using two main metrics: Processor (CPU) or Named User Plus (NUP).

Both apply to SE2 and EE (except some limits on SE2). Choosing the right metric depends on user counts and server configuration.

• Processor licensing counts the database server’s CPUs. For Standard Edition products, a “processor” means a CPU socket. For Enterprise Edition, count cores×core factor. Oracle provides a Processor Core Factor Table to adjust for chip architecture (e.g. many Intel/AMD cores have factor 0.5, older or high-end cores 1.0, some ARM 0.25). Always apply the factor, then round up.
  • Example: 8-core Intel Xeon (factor 0.5) requires 8×0.5 = 4 Processor licenses.
  • All servers running or able to run the database must be licensed. In a cluster (RAC), that means every node.
• Named User Plus (NUP) licensing counts end-users and devices. You buy one license per unique user or device that connects to Oracle. Multiplexing (connection pools, apps, etc.) does not reduce count – every human or non-human interface client is a “Named User”. Key points:
  • Minimums: Oracle enforces minimum NUP counts per server/processor. EE requires at least 25 NUP per processor (or per CPU license unit). For SE2, at least 10 NUP per server (since SE2 has a maximum of two sockets, this effectively means 10 per socket if two sockets). If there are more actual users, you license those.
  • Counting: Include all human users and any “non-human” users (machines, services) that access the DB. For example, two analysts sharing an app account still count as two NUP.
  • Choice: Use NUP when you can cleanly count users (e.g. intranet apps). Use Processor when the user count is high or unknown (e.g., public-facing site).

Table: Licensing Scenarios and Requirements

Core Factor and Calculations

When licensed by the processor, core factors adjust for CPU differences. Oracle publishes a Processor Core Factor Table that assigns a factor (0.25, 0.5, 1.0, etc.) to each chip type. Multiply physical cores by the factor, then round up: that’s the number of Processor licenses needed. For example, a 16-core server with an Intel CPU (factor 0.5) yields 16×0.5 = 8 licenses if the factor were 1.0 (like high-end SPARC or IBM z), 16×1.0 = 16 licenses.

Virtualization: Oracle allows sub-capacity licensing only under approved “hard partition” environments. Non-Oracle hypervisors (VMware, Hyper-V, generic Xen, Docker containers, etc.) are considered soft partitions. Oracle’s rule is that soft partitioning does not restrict licensing. For example, if you run a 2‑vCPU VM on a 32-core host under VMware, Oracle requires licensing all 32 cores. In other words, “Oracle explicitly states that VMware virtualization is considered soft partitioning…you still need to license the entire environment”.

Approved hard partitions include Oracle VM (with CPU pinning), Oracle Linux KVM (pinned), Solaris Zones, IBM LPARs, etc. You can isolate the database to specific cores and license only that subset.

In practice, true hard partitioning is rare and must be documented.

Key point: If you use a platform not on Oracle’s approved list, assume you must license every core in the cluster.

High Availability and RAC

Oracle offers high availability via Real Application Clusters (RAC) and related features. Licensing rules:

• Oracle RAC (Enterprise Edition): Treated as an option (see Options/Add-ons below). If you deploy RAC, every cluster node running the database must be licensed. For example, a 2-node RAC on 2×16-core servers would require licensing both 32-core servers fully (32×0.5=16 Processor licenses ×2). Data Guard’s standby alone (Active Data Guard) also must be licensed if the standby is open for read-only, but basic Data Guard (standby not open) is included.
• RAC One Node: A lighter “failover” RAC allowing one active instance at a time. It is similarly licensed per server; standby nodes may be discounted (often one free failover node per cluster). The Oracle Price List shows RAC One Node at ~$10k/license (NUP)/$10k CPU vs RAC at ~$23k.
• Failover and DR: Oracle generally requires licensing passive replicas if they can be active. For Data Guard: Primary is EE, standby with Active Data Guard is also EE+ADG licensed. (Basic Data Guard standby, not open, is often considered free for EE). Oracle often grants one free standby node per cluster in RAC (see Pricing slide example).

NAS/Shared Storage: If multiple DB servers mount the same disk, Oracle assumes that any of them can run the DB and requires licensing them all. An example slide shows four nodes sharing storage, and must license all four if the EE DB is installed on all.

Cloud Licensing: AWS/Azure/GCP vs Oracle Cloud

Oracle’s licensing rules change when moving to the cloud. On AWS/Azure/GCP (Authorized Cloud Environments), Oracle lets you bring your own license (BYOL), but with special counting rules.

Key points from Oracle’s policy:

• vCPU count: Count two vCPUs = 1 Oracle Processor license if hyper-threading (SMT) is enabled (common on EC2/Azure/GCP), otherwise 1:1 if disabled.
• Core factor: The normal core factor table does not apply in these clouds. Use the above ratio directly.
• Instance size: For SE2 and SE1, licensing is based on instance “socket” sizing. Instances ≤4 vCPUs count as 1 socket. Above four vCPUs, every four vCPUs (rounded up) count as another socket. Oracle limits SE2 to instances ≤8 vCPUs.
• Example: On AWS, a 4‑vCPU VM (with SMT) counts as 2 Oracle Processor licenses. On a 16‑vCPU VM, that’s 8 Processor licenses (since 16/2). If SE2 is used on AWS, 8 vCPUs is the max; at least 10 NUPs are needed for every eight vCPU block.

For Oracle Cloud Infrastructure (OCI) and Cloud@Customer, Oracle’s BYOL rules are more straightforward: one Oracle OCPU (Oracle vCPU) is treated as one Oracle Processor license. (An OCPU typically equals two hardware threads on Intel/AMD or one physical core on Ampere).

Oracle’s own cloud pricing can be “license included” or BYOL. Customers with active support can move perpetual licenses to Oracle Cloud without additional fees (they only pay support).

*When SMT/Hyper-Threading is off, one vCPU = 1 license.

Options and Add-Ons

Oracle EE can be extended with many options and management packs. These include (among others): Partitioning, Real Application Clusters (RAC), Active Data Guard, Database In-Memory, Tuning Pack, Diagnostics Pack, Label Security, Advanced Security, etc.

All are extra-cost and sold per the same metrics as the base DB.

Important rules:

• License Matching: You must license options at the same scale as the database. Oracle’s policy states: “Add-on products such as the Enterprise Options and Management Packs must match the number of licenses of the associated product”. In practice, if you deploy Partitioning, you need a Partitioning license for every processor/Core licensed for the DB.
• Same Metric: Options use the same metric (Processor or NUP) and count as the DB edition they augment. If processors license EE, options count processors too. If by NUP, options need the same NUP count.
• Not Included: Many features are not in SE2 (e.g., no in-memory, parallel, or Tuning Pack). They are either EE-only or require a separate purchase. Always verify which options are allowed in each edition.
• Pricing: Options are often a fraction of EE cost, but add up. For example, Oracle’s 2024 price list (USD) shows Partitioning, In-Memory, Security, etc. costing $11,500–$23,000 per Processor. (See Pricing below.)

Read more about Oracle Database License Models.

Virtualization Traps

Oracle licensing in virtualized environments is a common audit pitfall. In summary:

• Soft Partitioning is Ignored: Oracle treats most hypervisors as soft partitioning. Even if you carve out a VM with limited vCPUs on a big host, Oracle requires licensing all physical cores of all hosts that could run the VM.
• VMware/Hyper-V/Docker: These are not on Oracle’s approved “hard partition” list. Oracle’s documentation explicitly says, “VMware virtualization is considered soft partitioning… You still need to license the entire environment.” Containers (Docker/Kubernetes) are similar—licensing must cover the whole host unless it’s in a truly isolated hard partition.
• CPU Pinning: Even “pinning” a VM to a host usually doesn’t work unless that host is completely isolated from others (no vMotion, no shared clusters). Oracle’s stance: if there’s any chance Oracle could run on other hosts, those hosts must be licensed.
• Oracle VM and KVM: Oracle’s own hypervisors (Oracle VM Server, Oracle Linux KVM) support hard partitioning. If you pin vCPUs in Oracle VM, Oracle may accept licensing only the pinned subset. But this must follow Oracle’s exact rules.
• Cloud Instances: Public cloud (AWS/Azure/GCP) is officially licensed by vCPU (as above) and is an exception – use the cloud policy. Even so, hidden VM sprawl or unused instances can incur license charges.

Recommendation: Always get clear written guidance from Oracle or an expert on licensing your virtualization platform. Assume worst-case (license all cores) unless you have certified hard partitioning.

Read our Oracle Database Licensing FAQs.

Pricing Examples

Oracle licenses are expensive, so even small miscounts have a big impact. To gauge scale, here is an example from Oracle’s global price list (2024, USD):

These list prices illustrate scale. (Support fees are ~22% of the license price per year, and subscription term licenses cost ~20% of perpetual.)

Example calculation: A 4-socket, 16-core-per-socket server running EE with Intel CPUs (factor 0.5) has 64 cores. Processor license count = 64×0.5 = 32 licenses. At $47,500 each, that’s $1.52M list price (plus options, plus support). Using NUP instead would require 32×25=800 users (if you had that many).

Read Top 10 Facts about Oracle Database Licensing in Disaster Recovery Environments.

Real-World Use Cases

• Internal App (NUP): A company runs a CRM application on EE, with 100 employees (users). The server is 4-socket (32 cores, factor 0.5 ⇒ 16 proc). The processor model would require 16 licenses. The NUP model requires max(25×16=400, actual users 100) = 400 NUP. NUP is wasteful here; buying 16 Processor licenses (and then optionally 400 NUP if needed) is better. If there were 500 actual users, NUP could make sense.
• Public Website (Processor): Using processor licensing if your web portal has unknown or web-scale traffic. If it’s on a 2-socket AWS instance with eight vCPUs (2 per license), you need 4 Oracle licenses. On-prem with 8× cores (factor 1.0), you’d need 8.
• Development/Test (PE): A dev team has 5 DBAs who need EE features for development. Instead of EE, they could use Personal Edition: only $950 (list for PE NUP) or similar. They can’t run RAC on PE, so if they need RAC, EE would be needed.
• Cloud Migration (BYOL): A customer with 200 EE licenses moves a database to Oracle Cloud. They apply BYOL and pay only support (for an on-demand OCPU price), saving ~80% vs license-included. On AWS, to mirror 200 EE licenses, they calculate how many vCPUs/OCPUs that covers and size instances accordingly, per the vCPU rule.

These illustrate choices: NUP vs Processor depends on user counts and host size. Virtualization choices (e.g., physical vs. cloud) change license requirements and must be planned.

Read our case study on how we helped a UK company optimize its Oracle licensing.

Licensing Pitfalls and Vendor Leverage

Oracle licensing can be a minefield. CIOs and procurement teams should watch out for:

• Unclear Terms: Oracle’s agreements (OLAs, Master Agreements) contain boilerplates that grant Oracle broad audit rights. Watch for vague wording (e.g., “any backup or secondary use requires equal licensing”). Always negotiate explicit terms if possible.
• Audit Preparedness: Oracle frequently audits customers. Maintain clear records of usage, counts of users/devices, and hardware inventory. Hidden usage (e.g. dev/test copies, unused VM instances) can trigger compliance issues. Assume Oracle will count anything that can be counted.
• Soft Partitioning Illusion: As above, do not assume VMs limit licenses. License all potential hosts in a cluster. Vendors often push “licensed per VM” arguments, but Oracle’s policy overrides that. Always clarify with legal/licensing teams.
• Named User Ambiguity: Who counts as a “user”? Desktop applications connecting to the DB count each user. Shared accounts or web apps do not reduce NUP count. Beware indirect connections (e.g., data feeds or IoT devices may need NUPs).
• Minimums and Metrics: Underbudgeting for minimums is a trap. Example: Buying 5 NUPs for SE2 on a 2-socket server violates the 10-user minimum. Oracle may bill back-dated license purchases at list prices if an audit finds non-compliance.
• Option Dependencies: Some options require prerequisites. For example, using Data Guard may require EE and perhaps RAC. Using WebLogic Suite with certain DB features may have dependencies. Oracle states, “functional dependencies among products…must be licensed”. Ensure you understand the required base licenses.
• Vendor Leverage: Oracle often sells software and cloud together. Consider that decisions (e.g., moving to Oracle Cloud, signing an Unlimited License Agreement) might give Oracle a negotiating advantage. Always compare total cost vs. alternatives (AWS, Azure, open-source DBs).
• Contract Expiration: If the support for a perpetual license lapses, you lose rights to new releases and the ability to move to the cloud. Keep support current on needed licenses.

Procurement should consider independent Oracle license reviews. Third-party experts can find over-deployments or recommend cheaper license models. Always align licensing with architecture (e.g., consolidate DB to fewer servers to reduce cores, or switch metrics).

Recommendations

• Keep Inventory and Usage Records. Track every Oracle installation, user/device count, and virtual host. Accurate data makes audits transparent. Use SAM (Software Asset Management) tools if available.
• Review Architectures Regularly. Before upgrades or migrations, review licensing. If moving to cloud or new hardware, recalculate core counts and factor values. Don’t assume old licenses automatically cover new deployments.
• Prefer Hard Partitioning When Possible. If you virtualize, use Oracle-approved methods (Oracle VM, pinned KVM, etc.) to limit licensed cores. Physical partitioning (e.g., isolated clusters) can save license costs.
• Leverage BYOL Carefully. For cloud, use Bring Your Own License to reuse on-prem licenses (reduces cloud fees). However, calculate the required license counts under cloud rules. Compare “license included” rates vs BYOL total cost (support only).
• Negotiate Enterprise Agreements. If you use Oracle heavily, consider ULAs (Unreleased License Agreements) or multi-year cloud contracts to lock prices. However, negotiate clear terms on usage, audits, and exit clauses.
• Engage Experts. Oracle licensing is complex; get legal and/or third-party licensing consultants to review your license position. They can often negotiate better terms or uncover unused licenses.
• Plan for Minimums. When buying NUP licenses, ensure you meet Oracle’s minimums (10 for SE2, 25 for EE) or buy enough to exceed them. Factor in future growth.
• Audit and Clean Up. Periodically audit your environment before Oracle does. Identify unused servers or databases that can be decommissioned, and unused options that can be dropped. Deleting obsolete DBs can eliminate license costs.
• Document Everything. For every purchase or technical decision, get written confirmation of licensing rules from Oracle (or include them in contracts). If an Oracle rep makes verbal promises (e.g., about virtualization), insist on written proof.

By following these guidelines, CIOs and procurement can avoid common traps, negotiate from an informed position, and optimize Oracle Database licensing for their organizations. Always verify assumptions against official policies and keep up with Oracle’s frequent licensing updates.

Read our Oracle Licensing FAQs.

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit