Counting Oracle Processor Licenses on OCI Bare Metal vs VM Compute Shapes

OCI is the one cloud where Oracle sets both the shape definition and the license conversion rule, and the rule that matters is buried in a footnote to the Processor Core Factor Table rather than in any contract you signed. This page shows you exactly how OCPUs convert to Processor licenses on Flex VMs and bare metal, where the counting doubles without warning, and what to put in your ordering document before you migrate.

Where the Conversion Rule Actually Lives (And Why That Matters)

Before you model a single OCPU, understand where the number you are modelling comes from. The OCI BYOL conversion ratio is not stated in the cloud licensing policy PDF that everyone circulates. It sits in the footnotes at the bottom of the Oracle Processor Core Factor Table, which is where Oracle defines how existing Processor and Named User Plus licenses translate into OCPUs for OCI and Oracle Compute Cloud@Customer. That placement is not an accident of formatting. The Core Factor Table is a web page Oracle maintains and edits at will, and the policy document that everyone treats as governing, "Licensing Oracle Software in the Cloud Computing Environment" (policies in effect as of June 12, 2024), disclaims itself in its own opening text: it is for educational purposes, it may not be incorporated into any contract, and it is subject to change without notice.

Read that sequence again as a buyer. Your entire OCI migration business case, potentially eight figures of avoided license purchase, rests on two artifacts that Oracle can revise unilaterally, neither of which you signed. In 25 years of negotiating with this vendor, I have never seen Oracle retroactively invalidate a migration on this basis, but I have seen the ratio argued during audits by LMS reviewers who cited a newer version of the page than the one the customer screenshotted three years earlier. The defense is trivially cheap and almost never taken: restate the conversion ratio verbatim in your ordering document or in a signed amendment, with the shape families and OCPU counts you intend to run named explicitly. An OD term survives a policy edit. A footnote does not.

Your OCI business case rests on a footnote Oracle can rewrite without telling you, unless you put the ratio in the ordering document.

There are exactly two artifacts worth citing in a dispute: the Core Factor Table footnote as it read on the date you contracted, archived with a timestamp, and your own ordering document language. Vendor blog posts, Oracle sales emails, and advisory articles (including this one) carry zero contractual weight. Archive the page, date it, and get the sentence into the OD.

The Base Math: 1 Processor License = 2 OCPUs (Enterprise Edition)

The footnote ratio for Enterprise Edition is one Processor license per two OCPUs. Sixteen Oracle Database EE Processor licenses therefore support an OCI VM of up to 32 OCPUs under BYOL. Standard Edition converts at a different rate because SE has always been socket-counted rather than core-counted: one Processor license covers four OCPUs, subject to the hard SE2 ceiling of eight OCPUs per database, which means two SE2 Processor licenses is the practical maximum any single SE2 deployment can consume. On the Named User Plus path, programs carrying the 32-NUP-per-Processor minimum require 32 NUP for every two OCPUs of x86 capacity, and SE2 under NUP carries a floor of ten NUP licenses per instance for up to eight OCPUs.

Now the part the advisory market will not tell you cleanly. There is a live, unresolved contradiction in published guidance. One camp asserts one Processor license per OCPU on the reasoning that an OCPU is already defined as a full physical core, so four OCPUs needs four licenses and a 50-OCPU footprint needs 50 EE licenses. The other camp reads the footnote literally at two OCPUs per license. The same advisory firms have published both positions in different years, which tells you the interpretation is genuinely contested rather than settled. The gap is not academic: on a 64-OCPU estate it is the difference between 32 and 64 EE Processor licenses, roughly 1.5 million dollars in list license fees plus 22 percent annual support.

Do not try to win this by footnote exegesis during an audit, because the burden of proof will land on you and the LMS reviewer will arrive with the current version of the page. Resolve it commercially and in advance. Ask Oracle sales to confirm the ratio in writing for your specific shapes, then convert that email into an ordering document clause: "For programs licensed by Processor deployed on Oracle Cloud Infrastructure compute shapes, two OCPUs shall require one Processor license." Sales will sign it far more readily during a migration push than they will after you have already moved. If Oracle refuses to commit, treat that refusal as pricing information and model at 1:1 until they do. The same discipline applies to your soft partitioning boundary documentation, which is the other place OCI counting quietly inflates.

The Core Factor Table Does Not Apply, So Stop Modelling 0.5

The most expensive spreadsheet error I see in OCI migration business cases is not aggressive discount modelling, it is a stale multiplier. Oracle's cloud policy, the version dated June 12 2024, states plainly that when counting Processor license requirements in Authorized Cloud Environments the Processor Core Factor Table is not applicable. That single sentence deletes the 0.5 x86 multiplier you have relied on for fifteen years of on-premises counting. The failure mode is predictable: a team takes a 32-core x86 estate, remembers it was licensed at 16 Processor licenses under the 0.5 factor, then applies the OCI Enterprise Edition ratio of 1 Processor license to 2 OCPUs on top of that and concludes it has headroom for 64 OCPUs. It does not. The 16 licenses cover 32 OCPUs, full stop. The 0.5 has already been consumed on-premises; applying it again is double-discounting, and it produces exactly a 2x entitlement shortfall that nobody notices until an LMS reviewer pulls your tenancy usage report and compares OCPU-hours against your CSI. Note also that the advisory market is not unanimous on whether Enterprise Edition converts at 2 OCPUs or 1 OCPU per license, so cite the footnote to the Core Factor Table and your own ordering document, never a blog. For the on-premises rules that still govern your data center estate, use the Oracle Core Factor Table guidance. The practical rule for OCI is one line long: apply the OCPU ratio, then stop counting.

Bare Metal Licenses the Whole Host, Including Idle Cores

Bare metal removes the concept of provisioned capacity from the licensing conversation entirely. You have exclusive access to every core on the physical server, so every OCPU on that host is licensable whether or not a single database session ever touches it. A BM.DenseIO2.52 is a 52-OCPU obligation on the day you spin it up, even if the workload only needs 12. A BM.Standard.E6.256, Oracle's current 5th Gen AMD EPYC flagship at 256 cores and 3 TB of memory, is a 256-OCPU obligation: 128 Processor licenses at the 2:1 Enterprise Edition reading in the Core Factor Table footnote, or 256 under the 1:1 interpretation some Oracle field teams assert. That interpretive gap alone is worth roughly 5.7 million dollars at list on Database Enterprise Edition, which is why the ratio belongs in your ordering document and not in an email thread.

Watch the trend line, because it is the commercial story. Each generational refresh raises the minimum entry ticket for a bare metal Oracle footprint. E4 set the floor at 128 cores, E5 at 192, and the March 2025 E6 general availability pushed general-purpose x86 bare metal to 256 cores. The April 2026 Acceleron refresh holds at 192 cores for both Standard and DenseIO variants, with the DenseIO configuration adding 2.3 TB of memory and 81.6 TB of direct-attached NVMe. Oracle markets these as capacity wins. From a licensing seat they are fixed-size license units with no shrink lever: you cannot buy half a bare metal host, and Oracle's shape catalogue steadily retires the smaller ones. This is the opposite of the elasticity most buyers believe they are purchasing when they move to cloud. The defensive argument for bare metal is real but narrow, namely that a dedicated host draws a clean boundary against the cluster-wide claims described in our soft partitioning audit defense guidance, where in advisory engagements we have seen the licensable core base inflated by 2x to 5x. Buy bare metal only when that boundary argument is worth more than the idle cores it forces you to license, and model both ratio scenarios before you sign.

Bare metal is a fixed-size license unit with no shrink lever, which is the opposite of the flexibility buyers assume they are buying.

Flex Shapes Are the Entitlement-Sizing Lever Fixed Shapes Take Away

The commercial value of E5.Flex, E6.Flex, and the A-series Flex shapes is not performance, it is that they let you provision to your entitlement instead of provisioning to a hardware tier. If you hold 3 Oracle Database Enterprise Edition Processor licenses and you accept the 2 OCPUs per Processor reading in the footnote to the Processor Core Factor Table, you can stand up exactly 6 OCPUs with 18 GB of memory. A fixed shape pushes you into the next tier, typically 8 OCPUs and 64 GB, and those 2 extra OCPUs are licensable whether the database uses them or not. That is a 33 percent entitlement overrun bought purely by menu design. The discipline is to size the shape to the license pool, never the pool to the shape, and to write that rule into your OCI landing-zone standards rather than leave it to whoever provisions the instance.

The failure mode I see most often in advisory work is silent OCPU creep. Flex shapes resize online, so a scale-out event, an autoscaling policy, or a well-meaning DBA responding to a performance ticket can move an instance from 6 to 12 OCPUs in minutes, and nobody re-checks the entitlement until an audit letter lands 18 months later. Control it with a hard ceiling in your IAM policy and a monthly reconciliation. Keep the evidence: instance configuration history, OCPU change logs, and Resource Manager state files are the artifacts that prove the count held on a specific date, and they are far stronger than a spreadsheet assertion.

• Cap OCPU counts in IAM policy and in the Terraform module, not just in a runbook, so scale-out cannot exceed entitlement without a policy exception.
• Export instance configuration history and OCPU change logs monthly and retain them for the full audit window, typically 3 years.
• Reserve bare metal for cases where you are using dedicated hardware defensively, for example to bound a soft partitioning claim to a single host, and accept that you lose the sizing lever in exchange.
• Document the Flex shape sizing rationale in the ordering document, because Oracle's cloud policy is expressly non-contractual and revisable.

Arm Shapes Break the 1 OCPU = 1 Core Assumption

Most licensing models still carry the assumption that an OCPU is a stable unit. It is not. On x86 the OCPU maps to 1 physical core with 2 hardware threads, so 1 OCPU equals 2 vCPUs, and that remains the reference point for any cross-cloud comparison against AWS or Azure vCPU counting. On Arm the definition split between generations. On A1, built on Ampere Altra Q80-30, 1 OCPU is 1 core and 1 vCPU because each OCPU corresponds to a single hardware execution thread. On A2 and A4, built on AmpereOne M A06-36M, Oracle's own documentation and price list state that 1 OCPU equals 2 cores and 2 vCPUs, with two hardware threads per OCPU.

The consequence is blunt: a BYOL count validated on A1 is not portable to A2 or A4. A like-for-like OCPU migration, 40 OCPUs on A1 moved to 40 OCPUs on A4, doubles the underlying core base from 40 to 80. Whether Oracle bills you on cores or OCPUs depends on which reading of the footnote survives the conversation, and that ambiguity is exactly why you should never let an Arm refresh proceed on a "same OCPU count" business case. Recalculate from cores, restate the number in the ordering document, and remember that the Core Factor Table's 0.5 multiplier does not apply in Authorized Cloud Environments, so there is no discount waiting to absorb the difference.

BYOL Versus License Included: The Numbers That Decide It

Start with the list rates, because the hourly delta is the part everyone models and the part that matters least. Standard x86 VM compute runs $0.0255 per OCPU-hour plus $0.0015 per GB-hour, so a 1 OCPU / 8 GB VM lands at roughly $0.0375 per hour. AMD E4/E5 shapes sit near $0.03 per OCPU-hour, and Arm A1 is roughly half that. The real spread is in managed database: $0.336 per OCPU-hour license-included against $0.0807 per OCPU-hour BYOL, about 4x. On a 32 OCPU database estate running continuously, that gap is roughly $71,600 per year per 8 OCPUs of difference, which is why Oracle sales will happily quote BYOL and let you assume the entitlement question is settled. It is not. The test is whether your existing entitlement is supported, transferable to OCI, and large enough to cover the target shape, and on bare metal that means the whole host including idle cores. A BM.Standard.E5.192 is a 192 OCPU commitment, or 96 Processor licenses at the 2:1 Enterprise Edition reading. If you hold 60, BYOL is not a cheaper option, it is a compliance event.

If you hold 60 Processor licenses and target a 192 OCPU bare metal host, BYOL is not a cheaper option, it is a compliance event.

Two cases push license-included ahead of BYOL that finance teams routinely miss. First, entitlement you would otherwise terminate: if a support-line cull is on the table, as in the Costco support termination case, holding licenses alive purely to feed OCI BYOL cancels the saving you were chasing. Second, low-utilization workloads, where you pay 22% support on a perpetual asset that runs a few hundred hours a year. If you are running a multi-cloud bid, price the same workload against the AWS BYOL counting rules and the Azure BYOL and license-included comparison before you accept OCI's number, because the vCPU-to-license conversion differs on each and the cheapest hourly rate rarely survives the entitlement check.

What to Do First: Pin the Ratio Before You Migrate

Sequence matters more than analysis here. Do these five things in order, and do them before any workload moves.

• Pull the current Processor Core Factor Table, read the OCI footnote, and archive a dated PDF copy with a screenshot timestamp. Oracle states the cloud policy is non-contractual and revisable without notice, so your evidence of what the rule said on migration day is the only version you control. Our Core Factor Table guide covers what the footnote does and does not cover.
• Inventory entitlement by program and metric, including NUP minimums. A 32-NUP-per-Processor floor becomes 32 NUP for every two OCPUs of x86, and SE2 carries a 10-NUP-per-instance minimum for up to 8 OCPUs.
• Model both the 2:1 and the 1:1 Enterprise Edition readings side by side. Advisory sources genuinely disagree, and the difference on a 192 OCPU host is 96 licenses. Do not resolve it by opinion. Get the ratio written into your ordering document or an OCI-specific amendment.
• Size Flex shapes to your entitlement, not to workload ambition. A 6 OCPU Flex instance is a legitimate configuration; an 8 OCPU fixed shape you did not need is a permanent license liability.
• Treat any bare metal shape as a whole-host commitment requiring CFO-level approval, because idle cores license the same as busy ones.

On posture: raise the ratio question at renewal or during the OCI consumption commit negotiation, when Oracle wants your spend number and has a reason to concede language. Once you have deployed and the OCPUs are running, you have nothing to trade and the LMS conversation starts from Oracle's reading, not yours. If you are also virtualized on-premises, settle the soft partitioning exposure in the same negotiation rather than in two separate rounds.

Related advisory: the full topic guide.

Frequently asked questions

Does the Oracle Core Factor Table apply to OCI?

No. Oracle's cloud licensing policy states the Processor Core Factor Table is not applicable when counting Processor license requirements in Authorized Cloud Environments, and OCI is Oracle's own environment. The OCPU conversion ratio replaces it. Do not stack a 0.5 x86 multiplier on top of the OCPU ratio in your business case, because that produces roughly a 2x shortfall that surfaces at audit.

How many OCPUs does one Oracle Database Enterprise Edition Processor license cover on OCI?

Oracle's Core Factor Table footnote states one Processor license covers two OCPUs for Enterprise Edition, so 16 EE Processor licenses support a VM of up to 32 OCPUs. Some advisory sources argue for a 1:1 reading on the basis that an OCPU is already a physical core. The ratio is not contractual in the policy document, so get it stated in your ordering document rather than relying on a footnote Oracle can revise.

Do I have to license idle cores on an OCI bare metal shape?

Yes. Bare metal gives you exclusive access to the entire physical host, so all OCPUs on that host are licensable whether or not you provision or use them. A BM.DenseIO2.52 is a 52-OCPU obligation and a BM.Standard.E6.256 is a 256-OCPU obligation. Treat any bare metal Oracle deployment as a fixed, whole-host commitment with no downsizing lever.

Is 1 OCPU always equal to 1 physical core?

No, and this is the most expensive assumption on OCI right now. On x86 shapes one OCPU equals one core with two threads, so two vCPUs. On Arm A1 one OCPU equals one core and one vCPU, but on Arm A2 and A4 one OCPU equals two cores and two vCPUs. An A1-based license count is not portable to A4 without recalculating from scratch.

When does license-included beat BYOL on OCI?

License-included Autonomous Database lists around $0.336 per OCPU-hour against roughly $0.0807 per OCPU-hour BYOL, a spread of about 4x, so BYOL usually wins on steady-state footprints. License-included wins when the workload is spiky, the footprint is small enough that the entitlement would sit idle, or you plan to terminate support on the underlying licenses for annual savings. Model both against your actual support bill, not just the hourly rate.

What should be in the ordering document before we migrate Oracle Database to OCI?

Name the specific programs and metrics being brought, state the OCPU conversion ratio you are relying on for each edition, and confirm that the ratio survives Oracle's revision of the cloud policy document for the term of the agreement. Add language covering bare metal whole-host counting so there is no later dispute about idle cores. Raise all of this during the OCI consumption commit negotiation, when Oracle wants your signature, not after deployment.