OCPU Licensing Rules on OCI: Cores, Threads, and Factors

License counting on OCI looks deceptively easy. The platform gives you a single number, the OCPU count, and Oracle publishes a rule for converting that number into processor licenses. Two OCPUs per Enterprise Edition processor license on x86, four OCPUs per Standard Edition 2 license, done. Yet in practice this is the area where we see the most expensive mistakes, because the clean conversion rule sits on top of a set of definitions and conditions that are easy to get subtly wrong. An OCPU is not the same thing as a vCPU. A vCPU on OCI is not the same thing as a vCPU on AWS. The core factor that applies on premises does not apply in any hyperscale cloud, including Oracle's own, where a different policy document governs the count. And the number of OCPUs that matters for licensing is the number enabled right now, not the number you provisioned at launch, which means autoscaling and burst features can change your license demand without anyone filing a change request.

This article is the counting reference for our cluster on Oracle licensing and BYOL on OCI. The pillar covers strategy, entitlements, and the choice between license models. This piece covers the mechanics: what the units mean, how the conversion works for each edition, how OCI compares with other clouds, and where the counting traps hide. Everything here describes Oracle's published policy as we understand it at the time of writing, and because Oracle revises these documents, you should verify every number against the current versions before relying on it in a negotiation or an audit response.

What an OCPU actually is

An OCPU is Oracle's unit of compute on OCI, and on x86 shapes it represents one full physical processor core with hyperthreading enabled. Because each hyperthreaded core exposes two execution threads, one OCPU equals two vCPUs in the terminology that AWS and Azure use. This single definition explains most of the confusion in cross cloud comparisons: when someone says a workload needs eight vCPUs on AWS, the equivalent OCI x86 shape needs four OCPUs, and a team that provisions eight OCPUs out of habit has just doubled both their compute spend and their license exposure in one motion.

Two complications keep the definition from being universal. First, OCI now sells some shapes denominated in vCPUs rather than OCPUs, a change Oracle made partly to ease comparison with other clouds. On those shapes the unit on your invoice is a thread, not a core, so the conversion to licenses runs through a different multiplier. You cannot assume the unit; you have to read the shape specification. Second, Ampere Arm shapes such as the A1 and A2 families do not use hyperthreading at all. Each Ampere OCPU is a single core exposing a single thread, so one OCPU equals one vCPU on Arm. That changes both the performance equivalence and the licensing arithmetic, and Oracle's policy treatment of Arm capacity has its own rules that should be verified per shape and per product before you assume anything. The safe habit is simple: for every shape in your estate, write down whether the billing unit is a core or a thread, and whether hyperthreading is in play, before you count a single license.

How Oracle counts BYOL licenses on OCI

For Enterprise Edition database and the products licensed alongside it, the rule on OCI x86 shapes is that two OCPUs require one processor license. The logic mirrors the on premises core factor table: x86 processors carry a core factor of 0.5, so a physical core counts as half a processor license, and since an OCPU is a physical core, two of them add up to one license. An eight OCPU virtual machine running Enterprise Edition therefore consumes four EE processor licenses, plus four processor licenses of every separately licensed option and pack enabled on that database, because options such as Partitioning, Advanced Security, and Diagnostics Pack must be licensed at the same count as the base edition. Forgetting the options multiplier is one of the most common and most expensive counting errors we encounter, since a database with three enabled options effectively quadruples the license demand of its OCPU count.

Standard Edition 2 follows a different model. SE2 is not licensed by core factor but by socket equivalence, and on OCI the published conversion is one SE2 processor license per four OCPUs, counted in increments. SE2 also carries instance caps: Oracle limits the size of the compute instance on which SE2 may run in authorized cloud environments, historically capped at eight OCPUs per instance on OCI, and SE2 itself throttles the database to a fixed number of CPU threads regardless of what the shape offers. Those caps mean SE2 is extremely economical at small sizes and simply unavailable beyond the limit, a boundary that matters enormously when you plan growth. The full edition decision, including when SE2 stops being viable and what the move to EE really costs, is covered in our companion piece on database editions and options under BYOL.

The table below shows how the units translate at common shape sizes on x86. The license columns show base edition processor licenses only; remember that EE options multiply the EE column.

Verify each row against the current Oracle cloud licensing policy before using it in a compliance position, because both the conversion ratios and the SE2 caps are policy statements that Oracle can and does revise.

How OCI compares with AWS and Azure

Oracle publishes a separate policy document for licensing its software in what it calls authorized cloud environments, which covers AWS and Azure. Under that policy, the counting unit is the vCPU: when hyperthreading is enabled, two vCPUs count as one processor license for Enterprise Edition, and when hyperthreading is disabled, each vCPU counts as a full license. At first glance that looks identical to the OCI rule, since two vCPUs equal one OCPU equal one license either way. The difference is in what you get for the license. On OCI, one EE processor license covers two OCPUs, which is two full physical cores and four threads of compute. On AWS or Azure, the same license covers two vCPUs, which is two threads, the equivalent of one physical core. In effect, a BYOL license stretches across twice as much physical compute on OCI as it does in the other authorized clouds. That is a deliberate commercial design, and it is also simply a fact you can verify in the two policy documents side by side. We keep the observation factual rather than promotional: for license heavy estates the density difference is often the single largest line in a cloud comparison, and for estates with few Oracle licenses it may not matter at all. How that density advantage interacts with the choice between bringing licenses and renting them is the subject of our article on BYOL versus license included.

Named User Plus on OCI

Processor licensing is not the only metric that travels to the cloud. Named User Plus licenses can also be applied to OCI workloads under BYOL, and for small, internal, clearly bounded user populations they are often the cheaper entitlement to use. The catch is that NUP licensing carries per processor minimums that follow the processor count calculated exactly as above. For Enterprise Edition the historical minimum is 25 Named User Plus per processor license, so a four OCPU instance that converts to two EE processor licenses requires at least 50 NUP regardless of how few humans actually use the system. Standard Edition 2 uses a per server minimum, historically 10 NUP per server equivalent. Two consequences follow. First, scaling OCPUs up does not just raise a hypothetical processor count, it raises the NUP floor, and an autoscaling event can silently push a compliant NUP position below the minimum. Second, counting the users themselves is harder than it sounds, because NUP counts every human and every device that accesses the database directly or through any intermediary, including service accounts that front application traffic. Multiplexing through an application server does not reduce the count. As with everything in this article, the minimums are policy and contract numbers that you should verify against your own agreements and Oracle's current documentation, because older contracts sometimes carry different minimums than the current standard.

Counting pitfalls that surface in audits

The conversion rules are static; your estate is not. Most genuine compliance gaps on OCI come not from misreading the ratio but from the estate drifting away from the count someone wrote down at deployment time.

Autoscaling changes the answer. Any feature that changes enabled OCPUs changes license demand at that moment. Autonomous Database autoscaling can take a database to three times its base OCPU count, and Oracle's licensing treatment of that headroom must be understood before you enable it. Compute autoscaling on VM pools does the same for anything licensed by processor that runs on those instances. If your license position assumes a fixed core count, autoscaling has already invalidated it.

Burstable shapes complicate the baseline. OCI burstable instances run at a fraction of their provisioned OCPUs with the ability to burst to the full allocation. The licensing question is which number counts, the baseline or the ceiling, and the cautious reading licenses the ceiling because that is the capacity the software can use. Do not assume the favorable interpretation without verifying it in writing; auditors will not.

Dev and test environments count. There is no general free use right for nonproduction Oracle databases. A dev and test estate that mirrors production can double or triple your license demand, which is why disciplined teams keep nonproduction OCPU counts deliberately small, shut environments down outside working hours, and consider whether smaller editions or shorter lived instances can serve the purpose.

Failover and standby have specific rules. Oracle's failover policy permits limited unlicensed use on a designated standby in narrow circumstances, historically ten separate days per year on a single designated node in a cluster, while a running Data Guard standby that mounts or opens the database generally requires full licensing. The detailed conditions matter and change, so treat every standby, replica, and disaster recovery instance as licensable until you have verified otherwise against the current policy text.

Enabled core scaling and real time license demand

On Exadata Database Service and Base Database Service, the OCPU count is not fixed at provisioning. You enable and disable cores online, and the enabled count at any moment is the count that drives both the infrastructure bill and, under BYOL, the license demand. This is a genuine advantage when managed well: scale enabled cores down after a quarter end peak and your license requirement falls with them, something physical servers never offered. It is a genuine hazard when managed casually, because any administrator with console access can scale a system past the entitlement you own, and the platform will not stop them. The operational answer is to treat license entitlements as a hard quota in your scaling runbooks and to alert on enabled core changes across every BYOL system. The Exadata case has additional subtleties around minimum core counts and how licenses map across clusters, which we cover in BYOL on Exadata Cloud. For compute based deployments, shape selection and core management sit inside our OCI compute practice, where getting the OCPU count right is as much a licensing decision as a performance one.

A counting framework to run before any audit

When we baseline a client's position, the sequence below is the one we follow. It works as a self audit, and it is the same arithmetic an auditor will run, so running it first means you find the gaps before they do.

Getting the count right, and keeping it right

The OCPU rules reward teams that treat counting as a living discipline rather than a one time spreadsheet. The ratios are public, the definitions are stable enough to learn, and the density advantage on OCI is real and verifiable. What separates clean estates from audit findings is the operational layer: knowing the unit on every shape, watching enabled cores as they move, counting options and standbys honestly, and rechecking the policy documents on a schedule. This is work we build into engagements on whichever commercial model fits, a fixed project fee for a baseline and remediation, a Managed Monthly retainer where license aware monitoring runs continuously alongside the platform work, or an optimization engagement where our fee is a percent of verified savings, so if reworking shapes and core counts saves nothing, you pay nothing. However you run the count, run it before Oracle does, and anchor every number to the current policy text rather than to what was true when the system was built.