How OCI Measures Compute: OCPU Explained

Oracle Cloud Infrastructure uses OCPUs (Oracle Compute Processing Units) as its primary compute metric. Understanding what an OCPU represents is fundamental to understanding OCI licensing, because the OCPU definition determines how Oracle Database and other product licences are counted in the cloud.

One OCPU equals one physical CPU core on Oracle's underlying server hardware, with hyper-threading enabled. From a virtualisation perspective, one OCPU corresponds to two vCPUs in the OCI console — Oracle enables hyper-threading by default, so each physical core presents two logical threads. When an OCI VM shape is described as having "8 OCPUs," it has access to 8 physical cores and 16 vCPUs.

This distinction between OCPUs and vCPUs matters enormously for Oracle Database licensing on OCI. Oracle Database Processor licences are counted in OCPUs on OCI — not vCPUs. The fact that OCI uses physical core equivalents as its licensing unit means that Oracle Database BYOL on OCI is more favourable than on AWS or Azure, where Oracle's hard partitioning requirements can result in licensing based on the full physical host rather than just the assigned virtual machine.

BYOL on OCI: The 2-OCPU-per-Processor Rule

Oracle's BYOL programme on OCI allows organisations to apply existing perpetual Oracle Database Processor licences (and other eligible products) to OCI deployments at a specific mapping rate: 1 Processor licence covers 2 OCPUs on OCI. This is the single most important rule for understanding Oracle Database costs on OCI.

Practically, this means that an organisation with 100 Oracle Database Enterprise Edition Processor licences can deploy Oracle Database on OCI VM shapes totalling up to 200 OCPUs under BYOL. Any OCPUs beyond the 200 BYOL-covered allocation must either be covered by additional BYOL licences or by purchasing Licence Included at Oracle's standard rate.

The 2:1 ratio (2 OCPUs per Processor licence) is specific to OCI. On AWS and Azure, Oracle's BYOL rules apply differently — typically 1 Processor licence covers 2 vCPUs on those platforms, which on AWS or Azure means 1 physical core per Processor licence rather than the 2-OCPUs-per-Processor advantage OCI provides. This structural difference is a material competitive advantage for OCI when compared to hyperscaler alternatives for Oracle Database workloads.

BYOL Requirement: Active Support

BYOL licences on OCI must be covered by active Oracle annual support. Oracle's annual support fees on perpetual licences increase by 8% per year. Organisations migrating to OCI under BYOL continue paying on-premises support rates that escalate annually — the cloud migration does not change the support obligation on the BYOL licences. Any Processor licence with lapsed support is not eligible for BYOL until support is reinstated and back-support fees are paid.

Planning an Oracle Database migration to OCI?

We model BYOL vs Licence Included economics and validate your processor licence count before you deploy.
Request OCI Advisory →

Licence Included vs BYOL: Choosing the Right Model

OCI offers two licensing approaches for Oracle software running in the cloud: Licence Included (LI) and Bring Your Own Licence (BYOL). The choice between them drives significant cost differences and has strategic implications beyond the first-year bill.

Licence Included

Under Licence Included, Oracle bundles the Oracle Database licence cost into the OCI hourly compute rate. You pay a single per-OCPU-per-hour rate that covers both infrastructure and licence. No existing Oracle licence is required. LI is convenient for new Oracle workloads, short-duration projects, development and test environments, or situations where the organisation does not hold sufficient Processor licences to cover the planned OCI OCPU count under BYOL.

The LI rate is substantially higher than the BYOL compute rate — typically 40 to 60 percent higher for the same OCI VM shape and Oracle Database edition. For long-running production workloads, the cumulative cost premium of LI versus BYOL is significant. A 16-OCPU OCI VM running Oracle Database Enterprise Edition at LI pricing for three years may cost $300,000 to $500,000 more than the same VM under BYOL, depending on the specific service and shape chosen.

BYOL

Under BYOL, Oracle charges only for the OCI compute infrastructure — CPU cycles, memory, storage, and networking — without the embedded licence cost. The BYOL rate is lower precisely because Oracle considers the licence already paid through your existing Processor licence investment and annual support payments. BYOL is the appropriate model for any organisation with sufficient existing Processor licences and active support to cover planned OCI OCPU deployments.

The BYOL decision requires accurate licence inventory management. Before deploying Oracle Database on OCI under BYOL, the organisation must confirm: how many Processor licences are available, whether those licences have active support, and whether the available licences cover the planned OCPU count at the 2:1 ratio. Under-claiming BYOL coverage wastes savings opportunity; over-claiming creates compliance exposure.

OCI Universal Credits: The Committed Consumption Model

OCI Universal Credits are the primary commitment vehicle for OCI spending. Instead of paying on-demand rates for each OCI service, organisations commit to a minimum annual or multi-year spend in exchange for discounted rates. Universal Credits are pre-purchased in dollar amounts and drawn down as OCI services are consumed.

Universal Credits apply to any OCI service — compute, storage, database, networking, and managed services — from the same committed pool. This flexibility distinguishes Universal Credits from service-specific commitments: if your OCI strategy shifts from VM-based databases to managed Autonomous Database services, the Universal Credits pool accommodates the change without requiring a separate commitment instrument.

The discount available on Universal Credits correlates with commitment size and term. Larger annual commitments (typically above $100,000 per year) and longer terms (three years versus one year) attract greater discounts off Oracle's pay-as-you-go rates. Organisations should model their OCI consumption carefully before committing to ensure the commitment level is achievable — unused Universal Credits at contract end are forfeited under Oracle's standard terms unless rollover provisions are negotiated.

Soft Partitioning on OCI: A Compliance Simplification

One of OCI's material compliance advantages over competing hyperscalers is Oracle's acceptance of soft partitioning for licensing purposes within OCI. Oracle's standard policy on third-party hyperscalers (AWS, Azure, Google Cloud) requires hard partitioning — physical isolation — before Oracle will licence software based on the assigned VM's OCPU count rather than the full physical host's core count. On AWS and Azure, this typically means using Dedicated Hosts, which carry significant cost premiums and operational overhead.

On OCI, Oracle accepts that OCI's virtualisation technology provides sufficient isolation to allow Oracle Database licensing based on the OCPUs assigned to the specific VM shape, without requiring dedicated hardware. This soft partitioning acceptance means that a 16-OCPU OCI VM shape running Oracle Database requires BYOL coverage for 8 Processor licences (16 OCPUs ÷ 2 = 8 Processor licences) — regardless of how many OCPUs the underlying physical server has in total.

The same workload on AWS, without a Dedicated Host, would require licensing the entire physical host's cores — potentially 128 or more cores — because Oracle does not accept standard AWS virtualisation as hard partitioning. This difference in partitioning recognition is a structural advantage of OCI for Oracle Database workloads and should be included in any OCI versus hyperscaler cost comparison.

"On OCI, you licence the OCPUs assigned to your VM. On AWS without Dedicated Hosts, Oracle can require you to licence the entire physical server. The difference can be hundreds of Processor licences."

The ECPU Transition for Autonomous Database

Oracle introduced a new compute metric — ECPUs (Elastic Compute Processing Units) — for Autonomous Database services on OCI. Starting 28 May 2025, new Autonomous VM Clusters on OCI can no longer be provisioned with the OCPU compute model through the OCI Console. All new Autonomous VM Cluster deployments must use the ECPU billing metric.

Oracle has stated that it will also transition existing Autonomous VM Clusters and Autonomous Databases from OCPU to ECPU billing in future updates. Organisations running Autonomous Database workloads on OCI should plan for this transition and confirm the ECPU equivalent rate and BYOL mapping for their specific database configurations.

The ECPU transition affects only Autonomous Database services. Standard Oracle Database deployments on OCI VM shapes, Bare Metal instances, and Exadata Cloud Service continue to use the OCPU billing model with the standard 2-OCPU-per-Processor BYOL mapping. Organisations with mixed Oracle Database portfolios — some on Autonomous Database, some on standard VM shapes — need to track the two compute metrics and their respective BYOL entitlements separately.

OCI Cost Optimisation: Key Levers

Enterprises running significant Oracle Database workloads on OCI have several practical levers for cost optimisation beyond the foundational BYOL decision.

Right-Sizing OCI Shapes

Oracle offers OCI VM shapes across a wide range of OCPU configurations. Organisations frequently provision VM shapes larger than required for the workload, paying for OCPUs — and under BYOL, consuming Processor licence coverage — that are not being fully utilised. Regular right-sizing reviews, particularly for development, test, and non-production environments, reduce both infrastructure costs and unnecessary licence consumption from the BYOL pool.

OCI's flexible VM shapes allow OCPU counts to be adjusted without reprovisioning the instance in many cases. This dynamic resizing capability should be used proactively for workloads with variable demand, rather than maintaining maximum OCPU allocations continuously.

Oracle Support Rewards

Oracle's Support Rewards programme credits a portion of OCI consumption against the organisation's on-premises annual support bill. For Oracle Cloud Infrastructure consumption (including BYOL OCI deployments), Oracle issues Support Rewards credits at a rate of approximately 25 cents per dollar of OCI spend, which can be applied to reduce the next annual support invoice. For organisations with large on-premises support obligations, Support Rewards can meaningfully offset the effective OCI cost.

Support Rewards credits are separate from Universal Credits and require separate tracking. Organisations should confirm with their Oracle account team that Support Rewards are being properly accrued and applied at each annual support renewal cycle.

Oracle Fiscal Year Timing

Oracle's fiscal year ends 31 May. Oracle's Q4 (March through May) is the most active negotiating period for Universal Credits commitments, new BYOL deployments, and OCI infrastructure agreements. Oracle sales teams have strong Q4 incentives to close deals, and buyers who are prepared with clear commitments and realistic consumption models can secure meaningful discounts and commercial protections during this window that are harder to achieve at other times of year.

OCI vs Third-Party Hyperscalers for Oracle Workloads

The Oracle licensing rules are deliberately structured to make OCI more attractive than competing hyperscalers for Oracle Database workloads. The 2-OCPU-per-Processor BYOL ratio (versus 1-vCPU-per-half-Processor on hyperscalers), soft partitioning acceptance, and Oracle's Support Rewards programme all favour OCI over AWS, Azure, or Google Cloud for Oracle-intensive deployments.

However, total cost of ownership analysis must account for factors beyond Oracle licensing: OCI network egress costs, integration with existing cloud-native services on AWS or Azure, operational tooling expertise, and the organisation's existing cloud commitments and discounting structures. An organisation with a large Azure enterprise commitment or AWS private pricing agreement may find the total blended cost of Oracle on Azure or AWS favourable despite the licensing disadvantage, particularly if the Oracle Database workload is a small portion of a much larger cloud footprint.

For organisations considering Oracle Multicloud Universal Credits as a mechanism to balance OCI and hyperscaler Oracle deployments, the Multicloud Universal Credits guide covers the primary and secondary subscription structure and the unified rate card mechanics in detail.

For independent analysis of your OCI licensing position, BYOL optimisation, or Universal Credits negotiation strategy, visit our Oracle Knowledge Hub or contact our Oracle advisory team. We work exclusively on the buyer side — no Oracle relationship, no incentive to recommend any particular Oracle programme over another.