Oracle Database Licensing: The Complete Guide
Oracle database licensing runs on two metrics: Processor, where physical cores are multiplied by a core factor to give a licensable count, and Named User Plus, where every user is counted against a per processor minimum. The Enterprise Edition base, the separately licensed options and packs layered on it, and the partitioning rules that govern virtualisation are where almost all cost and audit exposure sit.
Oracle database licensing is the single largest line of Oracle spend for most enterprises, and the single most misunderstood. The rules are not secret, but they are scattered across price lists, policy documents, and contract definitions that each carry different legal weight. This guide assembles them into one reference, written from the licensee's side of the table.
The goal is not to recite Oracle's published positions. It is to show where those positions are contractual and binding, where they are policy that can be negotiated, and where the maths can be turned in the customer's favour before a number is ever signed. Read it as the foundation; the deeper articles linked throughout take each topic apart in detail.
Key findings
- 1Two metrics govern everything: Processor and Named User Plus. Choosing the wrong one for a given environment is the most common avoidable overspend.
- 2Options and management packs, not the database itself, generate the majority of audit findings, because they are trivial to enable and easy to use without entitlement.
- 3The partitioning policy that drives VMware claims is a published document, not a contract term. Its legal status is the centre of every virtualisation dispute.
- 4Most database audit triggers are visible in advance and can be remediated before an audit opens, which is where the largest savings are made.
How is Oracle database licensing calculated?
Every Oracle database licence resolves to one of two metrics. Under the Processor metric, you license the hardware: count the physical cores in the server, multiply by the core factor Oracle assigns to that processor type, and the result is the number of processor licences required. Under Named User Plus (NUP), you license the people: count every individual and every non human operated device that accesses the database, subject to a contractual minimum of 25 named users for each processor that would otherwise be licensed.
The two metrics describe the same database from different angles, and the cheaper of the two depends entirely on the ratio of users to cores. A small, internal application with forty known users on a large server is almost always cheaper under NUP. An internet facing system with an unknowable user population must be licensed by Processor, because you cannot count the users. The full comparison, including the minimums that distort the maths, is set out in the processor versus Named User Plus article.
Both metrics sit on top of an edition. The edition determines the base price and, critically, which options and packs are even available to license. Getting the edition right is the first decision; everything else follows from it.
Editions and what each one includes
Oracle ships the database in several editions, and the licensing consequences of each differ sharply. Standard Edition 2 (SE2) is licensed per socket with a hard cap on the number of CPU sockets and threads, and it cannot run most of the separately licensed options. Enterprise Edition (EE) carries no such cap, supports the full options catalogue, and is the edition under which nearly all large estates and nearly all audit exposure live.
The trap is that the powerful features live in EE plus options, and many of those features are enabled by default or switched on inadvertently during routine administration. A database installed as Enterprise Edition has every option present in the binaries; entitlement is a contractual matter, not a technical gate. That gap between what is installed and what is licensed is the structural reason database audits are so productive for Oracle.
For Standard Edition customers, the discipline is different: stay within the socket and thread limits, and avoid the temptation to use features that silently require Enterprise Edition. For Enterprise Edition customers, the discipline is to know exactly which options are entitled and to monitor whether any non entitled option has been touched, because Oracle's scripts will find it.
Processor versus Named User Plus
The choice between Processor and Named User Plus is the most consequential pricing decision in the database stack, and it is frequently made by default rather than by analysis. The NUP minimum of 25 named users per processor is the hinge. On a server that would require, say, eight processor licences, NUP demands a minimum of 200 named users even if only sixty people actually use the system. Below the minimum, you pay for users you do not have; above a certain real user count, Processor becomes cheaper because it is insensitive to how many people log in.
| Environment | Typical best metric | Why |
|---|---|---|
| Small internal app, few known users | Named User Plus | User count well below the processor minimum |
| Large internal app, thousands of users | Processor | User count exceeds the NUP break even point |
| Internet or public facing system | Processor | User population cannot be counted |
| Batch or machine driven workload | Depends | Non human devices still count as named users |
A subtlety that catches many estates: Named User Plus counts non human operated devices as users. A batch process, a sensor feed, or an integration account that touches the database is a named user. Estates that assume NUP only counts employees routinely undercount, which surfaces as a finding in an audit. The disciplined approach is to model both metrics for every database and choose deliberately, a calculation explained in full in the metric comparison article and applied across the database licensing service.
The core factor table
Under the Processor metric, you do not license cores one for one. Oracle publishes a core factor table that assigns a multiplier to each processor type, and the licensable processor count is physical cores multiplied by that factor. Most modern Intel Xeon and AMD EPYC processors carry a factor of 0.5, so a server with 32 physical cores requires 16 processor licences. Some processors carry a factor of 1.0, and a handful carry 0.25.
| Processor | Core factor | Physical cores | Processor licences |
|---|---|---|---|
| Typical Intel x86 | 0.5 | 32 | 16 |
| Typical AMD x86 | 0.5 | 64 | 32 |
| Factor 1.0 processor | 1.0 | 16 | 16 |
| Factor 0.25 processor | 0.25 | 32 | 8 |
Two rules surprise people. First, the core factor table is a policy document Oracle can revise, but the factor that applies is generally the one in force when the licence was acquired; the contract, not the current table, governs. Second, the core factor does not apply in Oracle's authorised cloud environments, where a different per vCPU or per OCPU counting applies. Hardware refresh decisions should therefore be made with the core factor in view, because moving to a processor with a higher factor can quietly increase the licence requirement. The mechanics are detailed in the core factor table article.
Options and management packs
If the database engine is the chassis, the options and packs are the expensive trim, and they are where audits are won and lost. Options such as Partitioning, Advanced Compression, Advanced Security, Real Application Clusters, In Memory, and the Multitenant container option are separately licensed features layered on Enterprise Edition. Management packs, principally the Diagnostics Pack and the Tuning Pack, license the use of certain Enterprise Manager features and database views.
The reason options dominate audit findings is structural: they are present in every Enterprise Edition install, they are easy to enable, and several are switched on by routine activity that an administrator would not associate with a licensing event. Querying certain performance views can constitute use of the Diagnostics Pack. Creating a partitioned table uses the Partitioning option. The database records this usage, and Oracle's audit scripts read those records.
The buyer side discipline is twofold: maintain a precise inventory of which options and packs are entitled, and monitor feature usage so that any drift between entitlement and use is caught and corrected internally before Oracle finds it. Where usage of a non entitled option is discovered, the remedy is often to disable the feature and document the remediation, not to capitulate to a purchase. The full catalogue, the usage triggers, and the remediation playbook are in the options and packs article.
Partitioning, VMware, and RAC
The word "partitioning" carries two unrelated meanings in Oracle licensing, and conflating them is a costly error. One is the Partitioning option, a database feature for dividing large tables. The other is hardware or software partitioning, the question of how Oracle counts cores in a virtualised environment. This section concerns the second.
Oracle classifies partitioning technologies as either hard or soft. Hard partitioning, which includes a defined list of approved technologies, bounds the licensable cores to the partition. Soft partitioning, into which Oracle places VMware vSphere, does not, in Oracle's view, limit anything: the company asserts that the database must be licensed for every physical core in the cluster, and in its most aggressive reading every core reachable by live migration or shared storage, that the database could run on.
The decisive point for the buyer side is that this partitioning policy is a published Oracle document, not a term of the licence agreement. Unless the signed contract incorporates it as binding, it is Oracle's interpretation, to be negotiated rather than obeyed. That single distinction is the foundation of most successful VMware defences, and it is examined in full in the database on VMware article.
| Technology | Oracle treatment | Licensable cores |
|---|---|---|
| VMware vSphere | Soft partitioning | All cluster / reachable cores (asserted) |
| Approved hard partitioning | Hard partitioning | Partition cores only |
| Physical dedicated host | Capacity bounded | Host cores only |
| Authorised cloud (OCI) | Cloud rules | Per OCPU counting |
Real Application Clusters (RAC) is a related trap. RAC is itself a separately licensed option, and every node in a RAC cluster must be licensed for the database and for RAC. On Enterprise Edition the RAC option is chargeable; estates that built a RAC cluster for availability without licensing the option on every node carry exposure that an audit will surface. Architecture is therefore a licensing lever in both directions: isolating a database on a dedicated, bounded host limits exposure, while sprawling shared infrastructure maximises the core count Oracle can assert.
What triggers a database audit?
Oracle audits are rarely random. They are prompted by signals, most of which are visible to the customer in advance. Understanding the triggers is the prerequisite to controlling the timing, because a customer who remediates before an audit opens is in a far stronger position than one who is surprised by a script.
- Option and pack usage. Feature usage data that implies use of a non entitled option is the most common trigger and the most productive finding.
- Virtualisation. A VMware deployment, especially on large shared clusters, invites a partitioning based claim.
- Mergers and acquisitions. A transaction changes the legal entity and the deployment footprint, and Oracle reviews entitlement transfer closely.
- ULA expiry. The period around an unlimited licence agreement ending is a natural audit window.
- Large renewals. A significant support renewal or a cloud proposal often comes paired with a compliance review.
The response to a live audit is a discipline in itself: control the data Oracle receives, validate every finding against the actual contract before conceding anything, and separate genuine shortfalls from policy assertions that are open to challenge. That end to end response is the work of the audit defence practice, and the recurring patterns are anonymised in the case studies.
The timing point is worth stressing. A customer who maps these triggers and remediates ahead of them controls when the conversation happens and on what evidence; a customer who waits is reacting to Oracle's data on Oracle's schedule. The difference between those two postures is frequently larger than any single technical argument, because leverage in a licensing negotiation flows from preparation and optionality, not from being right after the fact.
Cloud, BYOL, and the ULA
Three structures sit above the per database metrics and reshape the whole calculation. The first is Bring Your Own Licence (BYOL), which lets existing Processor or NUP entitlements be applied to Oracle Cloud Infrastructure or, under specific rules, to authorised third party clouds. BYOL conversion ratios are a frequent source of dispute, because the ratio between an on premise processor licence and a cloud OCPU is not always one to one and is easy to misapply in either party's favour.
The second is the cloud counting model itself. In Oracle's authorised cloud environments the core factor table does not apply; capacity is counted per OCPU or per vCPU under separate rules. A migration that looks cheaper on headline pricing can be more expensive once the counting model is applied correctly, which is why a cloud move should be modelled on the actual conversion rules rather than the sales narrative.
The third is the Unlimited Licence Agreement (ULA), a time bounded right to deploy certain products without counting, which converts to a fixed perpetual entitlement at certification. A ULA changes database licensing from a counting exercise into a deployment maximisation and certification exercise, with its own distinct discipline covered across the ULA cluster and the ULA negotiation service. For the structured long form treatment of the database rules in this guide, see the Oracle database licensing white paper.
What unites BYOL, the cloud counting model, and the ULA is that each detaches licence cost from the simple per database metric and ties it to a larger commercial structure. A decision that looks like a technical migration is in fact a contract negotiation, and the counting model, the conversion ratio, and the certification position are all levers within it. Treating a cloud move or a ULA as a procurement event rather than an infrastructure event is the single biggest mindset shift that separates estates that save money on these transitions from those that lock in years of avoidable spend.
Standard Edition 2 and the socket cap
Standard Edition 2 is a genuinely different licensing regime from Enterprise Edition, and treating it as a cheaper version of the same thing is a mistake. SE2 is licensed per occupied CPU socket, subject to a hard cap on the number of sockets a server may have, and it imposes a thread limit on each database instance regardless of how many cores the hardware contains. The core factor table does not apply, and most of the chargeable options that drive Enterprise Edition audit findings cannot be licensed on SE2 at all.
The appeal of SE2 is real for the right workload: predictable per socket pricing and freedom from the options exposure that dominates Enterprise Edition audits. The risk is the edge of the box. A workload that outgrows the socket cap or the thread limit, or that requires a feature available only in Enterprise Edition, forces a conversion to Enterprise Edition where the core factor and the full options surface suddenly apply. That conversion is one of the most expensive transitions in the database stack, because it can multiply the licence requirement many times over. The discipline for SE2 customers is to stay deliberately within the box and to treat any pressure toward an Enterprise Edition only feature as a major commercial decision, not a technical one.
Support cost and the repricing trap
Licence acquisition is only the visible part of Oracle database cost. The larger part, over the life of an estate, is the annual technical support fee, charged as a percentage of the net licence fee originally paid and rising each year. Support is where the consequences of every metric, edition, and quantity decision compound, and it is governed by repricing rules that make a support stream far easier to grow than to shrink.
The trap is that partial reductions are penalised. Oracle's repricing policy means that attempting to drop support on a subset of licences can trigger a recalculation that reprices the remaining licences at a higher effective rate, erasing much of the intended saving. This is why shelf ware, licences bought and never deployed, is so costly: it carries support indefinitely and resists clean removal. The buyer side discipline is to right size at acquisition, to avoid accumulating unused entitlements, and to address support reduction at a structural moment such as a renewal, a consolidation, or a cloud move, where the whole position can be renegotiated rather than nibbled at the edges.
Multitenant and consolidation
The Multitenant architecture, in which multiple pluggable databases share a container database, is central to Oracle's consolidation story and carries its own licensing nuance. A limited number of pluggable databases per container is permitted without the separately chargeable Multitenant option; beyond that threshold the option is required. Consolidation projects that pack many pluggable databases into a container to improve density routinely cross the threshold without the option being licensed, creating an exposure that an audit will surface.
Consolidation also interacts with the metric and the core factor in ways that can cut either direction. Packing databases onto fewer, denser servers can reduce the total processor licence count if it is done with the licensing in view, or inflate it if the consolidation lands on higher core counts without the licence delta being modelled. The discipline is to treat consolidation as a licensing exercise as much as an engineering one, modelling the option threshold, the metric, and the core factor together before the architecture is committed, the same combined analysis that underpins the options and packs and core factor work.
Mergers, acquisitions, and entitlement transfer
A merger or acquisition is one of the most reliable triggers for an Oracle review, because it changes both the legal entity that holds the licences and the deployment footprint those licences cover. Oracle licences are granted to a defined legal entity, and the right to transfer them to an acquirer or a divested entity is governed by assignment clauses that are frequently restrictive. A transaction that assumes licences move freely with the assets can find that the entitlement does not transfer cleanly, leaving the new entity deploying software it does not have the right to use.
The exposure runs in both directions. The acquiring entity inherits whatever compliance gaps existed in the target, including unlicensed options and uncounted users, and Oracle reviews these closely at the point of transaction. A carve out or divestiture must establish which entitlements follow the divested business and whether they can be assigned at all. The disciplined approach is to treat Oracle entitlement as a diligence item in any transaction, mapping deployment against transferable entitlement before close, work that sits alongside the broader compliance discipline and the audit defence practice.
A database licensing maturity model
Drawing these threads together, it helps to think of database licensing control as a maturity curve rather than a binary state. At the lowest level, an organisation knows what it has bought but not what it has deployed, and discovers the gap only when Oracle audits. One level up, it maintains an entitlement inventory but does not actively monitor deployment, so drift accumulates between checks. Higher still, it reconciles deployment against entitlement on a regular cadence and catches drift within weeks. At the highest level, licensing is a design input: hardware, virtualisation, consolidation, and cloud decisions are all modelled for their licence impact before they are made.
The progression matters because the cost of control falls as maturity rises. An organisation at the top of the curve spends modestly on continuous monitoring and almost never faces a surprise finding; one at the bottom faces periodic large claims and pays for control reactively under audit pressure, when leverage is lowest. The buyer side method is to move an estate up this curve deliberately: establish the entitlement baseline, instrument deployment monitoring, fold licensing into architecture decisions, and revisit the position at every renewal and transaction. The remaining sections of this cluster, on metric choice, the core factor, options and packs, and VMware, are the working tools for each stage of that progression.
The buyer side view
Oracle database licensing rewards precision and punishes assumption. The estates that overspend are not careless; they are usually well run shops that accepted a default metric, enabled a useful feature without checking entitlement, or built a virtualisation architecture for engineering reasons without seeing the licensing consequence. None of these is a moral failure. Each is a measurable, recoverable position once it is brought into the light.
The buyer side method is to measure the estate against the contract that actually exists rather than the policy Oracle prefers, to model both metrics for every database, to inventory and monitor options and packs continuously, and to architect for bounded capacity before an audit forces the question. Done early, this is inexpensive and routine. Done under audit pressure, the same work is still effective but the leverage has shifted. To assess your database position before Oracle does, request a consultation.
Common questions.
How is Oracle database licensing calculated?
Oracle database licensing is calculated on one of two metrics: Processor, where physical cores are multiplied by a core factor from Oracle's core factor table to give a licensable processor count, or Named User Plus, where every human and non human user with access is counted against a per processor minimum. The lower cost metric depends on the ratio of users to cores.
What is the Oracle core factor?
The core factor is a multiplier Oracle assigns to each processor type in its core factor table. The licensable processor count equals physical cores multiplied by the core factor. Most modern Intel and AMD chips carry a 0.5 factor, so a 32 core server requires 16 processor licences, while some chips carry a factor of 1.0 or 0.25.
What are Oracle database options and management packs?
Options such as Partitioning, Advanced Compression, Advanced Security, and the Diagnostics and Tuning management packs are separately licensed features layered on top of Enterprise Edition. They are easy to enable and frequently used without entitlement, which makes them the single largest source of surprise findings in database audits.
Does VMware require licensing every host in the cluster?
Oracle's partitioning policy treats VMware as soft partitioning and asserts that every physical core the database could run on must be licensed. That policy is a published document, not a contract term, so whether it binds you depends on your agreement and how the environment is architected.
What triggers an Oracle database licence audit?
Common triggers include enabling options or packs without entitlement, virtualisation on VMware, mergers and acquisitions, a lapsed or expiring ULA, large support renewals, and self reported deployment data that does not match Oracle's records. Most triggers are visible in advance and can be remediated before an audit opens.
Is Named User Plus or Processor licensing cheaper?
Named User Plus is usually cheaper for environments with a small, countable user population, while Processor is cheaper for large or unknown user populations such as internet facing systems. The Named User Plus minimum of 25 named users per processor sets a floor that often makes Processor the better choice above a certain user count.