BYOL vs License-Included on ExaCC: Side-by-Side Maths, Break-Even Analysis and the Hybrid Pattern That Wins

Why the BYOL vs LI decision is the largest variable on ExaCC

The infrastructure subscription is fixed; the per-ECPU consumption is variable; and the rate at which the per-ECPU consumption bills is the BYOL vs LI choice. On a 5-year ExaCC deployment, the BYOL vs LI decision swings the total cost by 50-200% depending on utilisation. It is the single largest variable input on the ExaCC business case.

The decision is reversible mid-contract - a customer can switch from LI to BYOL by applying perpetual licences to the consumption pool, or from BYOL to LI by removing the perpetual coverage. The switch requires Oracle approval but is routinely granted. The decision is not, however, costless to switch: a customer who oversizes perpetual licence purchases for BYOL has spent money on entitlements that may not be needed; a customer who undersizes BYOL coverage faces audit exposure where activation exceeds entitlement.

The wider ExaCC framework sits at Cloud@Customer cost; the pricing anatomy is in ExaCC pricing anatomy; the BYOL framework across multi-cloud Exadata variants is in Multi-cloud BYOL rules; the broader optimisation framework is in the Licence Optimisation Guide.

Side-by-side rate comparison 2026

The published 2026 rates on ExaCC for the base Database EE and the most-used options:

The BYOL rate is roughly 73-75% lower than the LI rate across all SKUs. The discount reflects Oracle's view of the perpetual licence as covering ~75% of the cost of the right-to-use embedded in the LI rate, with the remaining 25% covering platform integration, Premier Support and the OCI control plane.

The conversion ratio: 1 Oracle Database EE Processor licence covers 4 ECPUs of ExaCC consumption (= 2 OCPUs on the legacy unit, both equivalent to the same physical compute). 1 Oracle Database SE2 Processor licence covers 8 ECPUs of ExaCC consumption (where SE2 is permitted on the platform - SE2 is restricted on Exadata in most contexts; see the Oracle Database Licensing Guide).

Break-even analysis at four utilisation profiles

The break-even between BYOL and LI is not 'BYOL is always cheaper'. It depends on what fraction of the year the ECPUs are activated. Four common utilisation profiles:

The math is sensitive to the assumed cost of the perpetual EE Processor licence. At full list ($47,500 per licence) the BYOL amortisation is heavier and break-even shifts toward higher utilisation. At deep-discount licences (e.g., 65-75% discount on volume), BYOL amortisation drops and break-even shifts down. Most enterprises with substantial perpetual EE pools acquired at historical discount land near break-even at 40-50% utilisation.

The strategic insight: BYOL is not 'always cheaper' - it is cheaper when ECPUs are activated at high utilisation. Customers with sparse activation patterns may find LI delivers the same cost outcome without the perpetual licence commitment.

Option-level BYOL vs LI patterns

The base Database EE BYOL decision often gets discussed independently of the options. This is a mistake: the options decisions stack and can dominate the base.

A continuously-activated 64-ECPU workload using Partitioning + Diagnostics Pack + Tuning Pack + Advanced Compression on ExaCC:

The options BYOL is worth $400K-$500K per year on its own. Customers who BYOL the base EE but not the options pay 4x what they need to on options. The reverse pattern (BYOL options but not base) does not work - the options cannot exist without the base licence.

The correct pattern: where BYOL works for the base EE, it almost always works for all options the customer actually uses. The customer's perpetual pool should be sized to cover the base plus the options pattern, not just the base.

The hybrid pattern that wins on most real deployments

Most real ExaCC deployments mix continuously-activated VM clusters (production OLTP databases, always-on consolidated workloads) with intermittently-activated ones (test/dev environments, batch-only databases, DR standbys that activate rarely). The cost-optimal pattern matches BYOL to the continuous workloads and LI to the intermittent ones.

The hybrid contract structure:

1. The customer maintains a perpetual EE Processor pool sized to cover the continuously-activated VM clusters (at the 1:4 ratio). The pool covers BYOL consumption on those clusters.
2. Intermittent VM clusters are activated under License-Included rates. No perpetual licence allocation - the consumption is paid for in the LI rate as activation occurs.
3. The customer maintains a quarterly reconciliation: are the perpetual licences correctly allocated to the BYOL clusters; are the LI clusters correctly metered as LI; do any clusters need to shift between the two as utilisation patterns change.

Operational complexity: low. The OCI Console allows VM clusters to be tagged as BYOL or LI at provisioning; the consumption meter applies the corresponding rate. The reconciliation is a quarterly review, not a real-time process.

Contractual complexity: low. The ordering document defines the customer's perpetual EE pool and the corresponding BYOL coverage; the LI consumption is metered at standard rates against Universal Credits or pay-as-you-go.

Cost outcome: typically 15-25% lower total cost than either pure BYOL or pure LI on the same workload mix.

Audit treatment of mixed BYOL / LI deployments

LMS audit of mixed BYOL / LI ExaCC deployments examines two things: (a) is the BYOL allocation correctly matched to the perpetual entitlement pool, and (b) are the BYOL-flagged VM clusters within the BYOL coverage of the allocated entitlements.

The audit script set queries the OCI Console for the VM cluster BYOL flag, the activation history (peak ECPU activation across the audit window), and the customer's CSI inventory for perpetual EE Processor entitlements. The auditor computes: required BYOL coverage = peak activated ECPUs on BYOL clusters / 4. If required coverage exceeds the entitlement pool, the difference is the audit finding.

The defence patterns:

• Maintain an explicit BYOL allocation register that maps perpetual entitlements to specific BYOL VM clusters. The register is the customer's authoritative record - it overrides any inference the auditor draws from the OCI Console.
• Refresh the allocation quarterly. Perpetual entitlement changes (acquisitions, ULA exits, support terminations) shift the pool; the register needs to track.
• Peak-activation document. Maintain a record of peak ECPU activation per VM cluster over the audit window. LMS uses peak, not average; the customer should also use peak to size BYOL allocation.

The wider audit framework is in the Oracle Audit Guide; the BYOL allocation framework is in Multi-cloud BYOL rules.

Decision framework: which model fits which workload

The decision framework in 2026 distils to four questions:

1. What is the activation utilisation? Above ~60% utilisation, BYOL is almost always cheaper (assuming an existing perpetual pool acquired at standard discount). Below ~30% utilisation, LI is almost always cheaper.
2. Does the customer have an existing perpetual pool? If yes, BYOL leverages existing investment with no incremental licence purchase. If no, the BYOL choice requires a fresh perpetual licence purchase, which shifts the break-even significantly toward LI.
3. What is the workload pattern - continuous or intermittent? Continuous workloads suit BYOL; intermittent workloads suit LI. Hybrid deployments allow workload-by-workload optimisation.
4. What is the Support Rewards offset? ExaCC consumption (both LI and BYOL) generates Support Rewards. The credits offset perpetual Premier Support invoices. Customers with large perpetual support bills find that LI consumption can be effectively 'free' on the net cost basis because it converts directly to support credit. See the Oracle Support Cost Reduction Guide.

The decision is not binary. The cost-optimal pattern is almost always a hybrid: BYOL on the continuous, high-utilisation workloads where the perpetual pool covers; LI on the intermittent, sparse workloads where the LI rate is the right meter.

Frequently asked questions

Is BYOL always cheaper than License-Included on ExaCC?

No. BYOL is cheaper when ECPUs are activated at high utilisation (typically above 60% of the year) and the customer has an existing perpetual EE Processor pool acquired at standard discount. For intermittent or low-utilisation workloads, License-Included is often cheaper on a total-cost basis because the perpetual licence amortisation exceeds the LI rate savings.

What is the BYOL ratio on ExaCC?

1 Oracle Database EE Processor licence covers 4 ECPUs of ExaCC consumption. This is equivalent to 1 Processor = 2 OCPUs on the legacy unit (the underlying compute is identical). For Database options, the ratio is the same as the base EE - 1 option Processor licence covers 4 ECPUs of that option's consumption.

Can I mix BYOL and License-Included on the same ExaCC?

Yes. VM clusters are tagged BYOL or LI at provisioning, and the consumption meter applies the corresponding rate. The customer maintains a BYOL allocation register matching perpetual entitlements to BYOL clusters; LI clusters meter consumption against Universal Credits or pay-as-you-go. The hybrid pattern is the cost-optimal default for most real ExaCC deployments.

Do I need to BYOL the Database options separately from the base EE?

Yes. The options pool is separate from the base EE pool. A customer with BYOL coverage for the base EE but no options coverage pays License-Included rates for any options consumed - typically 4x the BYOL rate. The options BYOL pattern is usually worth as much or more than the base BYOL because options stack: 4-5 options on a 64-ECPU cluster generates $400K-$500K of annual savings under BYOL vs LI.

Does Support Rewards apply to BYOL consumption on ExaCC?

Yes. ExaCC consumption is eligible for Support Rewards drawdown regardless of whether the consumption is BYOL or LI. The 25% credit rate applies on the consumption invoice value (the infrastructure subscription + per-ECPU + options). The credits offset perpetual Premier Support invoices. For BYOL-heavy deployments, the consumption invoice value is lower (because BYOL rates are ~73% lower than LI), so the Support Rewards credit is also lower in absolute terms - but typically still material enough to fully offset the BYOL'd perpetual support bill.

Related Oracle licensing reading