Oracle BYOL vs license included on OCI and Exadata Cloud@Customer. Where the crossover sits for each workload.

BYOL beats license included only when the yearly rate saving exceeds the support you must keep paying on the licenses, and only when those licenses are free of on premises work. Support Rewards and options then shift the answer again.

What is the difference between Oracle BYOL and license included on OCI?

They are two ways of paying for the same database service. License included bundles the Oracle software rights into the cloud rate, so you pay one higher price and Oracle carries the entitlement. Bring your own license (BYOL) applies licenses you already own and drops you to a lower infrastructure rate.

Oracle describes both models on its bring your own license page, and both rates sit side by side in the cloud price list. Neither document tells you which one is cheaper for you. That depends on your existing contract, which is why this is a purchasing decision more than a technical one.

What each model carries, line by line

What bring your own license costs you besides the rate

• Simplicity. You now count entitlements in two places and reconcile them. Oracle can audit the cloud claim like any other deployment.
• Feature headroom. The higher service tiers switch on options. If you own base Enterprise Edition only, those tiers are closed to you.
• Cloud spend. A lower bill looks like a win until you count the Support Rewards that the higher spend would have earned.
• Room to scale down. A license is a fixed asset. Running the service below what you own refunds nothing, and the support invoice arrives either way.

What it gains you

• A materially lower rate on the same service, and the gap compounds across a commitment of several years.
• Value from sunk cost. Perpetual licenses you paid for years ago keep working instead of sitting idle.
• Portability. The license is yours, so it can move to another cloud, back on premises, or into a renegotiation.
• Two prices instead of one. A customer who can credibly run either model has two quotes to compare at every renewal. A customer who cannot has to accept the one Oracle offers.

How do you calculate the crossover between BYOL and license included?

Use one inequality per workload. BYOL is cheaper when the rate saving over a year is larger than the annual support you keep paying to hold the licenses you dedicate to that workload.

The formula and where each input comes from

Let D be the rate difference per unit hour between the two models on the same service, H the unit hours the workload consumes in a year, and S the annual support on the licenses you dedicate to it. BYOL wins when D multiplied by H is greater than S.

• Take D from your own quote. It varies by service, edition, service tier and metering unit, so a figure from a blog or a competitor's deal will mislead you.
• Take H from measured usage. Check whether the service actually stops overnight. Most production databases do not.
• Take S from your support invoice, not from 22 percent of list. Oracle charges support on the net license fee you actually paid, which after discount is usually lower.
• Set S to zero only if you can prove it. If the support cannot be cancelled, it is sunk under both models, and license included gets no credit for it.

A worked example on a production database

Take a production database sized at 16 OCPUs and running continuously. Oracle's BYOL ratio for Enterprise Edition is one Processor license for every two OCPUs, so the workload needs 8 Processor licenses. The rate delta of $0.50 per OCPU hour is illustrative. Replace it with the number on your quote.

Read the 19 OCPU figure with care. It assumes support stays fixed while the workload grows, and it does not: 16 OCPUs already use all 8 licenses, so every OCPU you add brings more support with it.

Per OCPU, support runs $5,225 a year ($83,600 divided by 16) while continuous running saves $4,380 ($0.50 x 8,760). On these inputs the owned licenses never pay for themselves, at any size. Two things would change that answer.

• A wider rate delta. Anything above about $0.60 per OCPU hour on your actual quote tips a continuously running workload to BYOL.
• Support you cannot cancel anyway. If the support stays on the invoice under both models, S drops out and BYOL wins on the rate alone.

Rebuild the table with your own D and S before you trust either verdict.

Why part time workloads tilt toward license included

The support side of the inequality runs every hour of the year. The rate side only counts hours the service is billed. On Base Database Service, stopping a node stops its OCPU or ECPU billing, while storage keeps billing. Any workload that sleeps shrinks D x H while S stays where it was.

Against $83,600 of support, neither part time pattern comes close. If a test system runs on licenses you could drop, license included is almost always the cheaper home for it.

The support rule that breaks most termination plans

Oracle's technical support policies contain provisions on matching service levels and on pricing following a reduction of licenses. In practice, you cannot drop support on part of a license set and keep the old price on the rest. Oracle reprices the lines that remain.

That one rule decides more of these comparisons than the rate card does. If cancelling support on the freed licenses raises the price of the survivors, the saving you modeled on the license included side does not exist.

How does Oracle Support Rewards change the BYOL comparison?

It works against BYOL, and most cost models leave it out. Rewards are earned on Oracle cloud spend and credited against your technology support invoices, so spending less in the cloud earns you less off your support bill.

How the program works

• Earn rate. Oracle's Support Rewards program returns 25 cents for every dollar of Oracle cloud spend, and 33 cents for customers holding an unlimited license agreement.
• What earns. Consumption under a Universal Credits order, including BYOL services on that rate card. Pay as you go accounts do not qualify.
• What it offsets. Technology license support invoices only. Applications support is excluded, and rewards cannot be turned into cash.
• The ceiling. You can accrue without limit, but you can only apply rewards against your technology support bill. Anything above that line is wasted.
• Expiry. Rewards are calculated monthly and stay valid for 12 months after they are deposited.
• Ownership. Rewards accrue on cloud spend and land on support renewals, so the two lines usually sit in different budgets with different owners.

The reversal, worked

Say the same service costs $1.0 million a year of cloud spend under license included and $400,000 under BYOL. Assume your technology support bill is large enough to absorb every reward.

At 25 cents the model was a quarter wrong before anyone negotiated a rate. At 33 cents the gap narrows further. For customers with a very large support base and a modest cloud footprint, we have seen it close entirely.

When the cap works in BYOL's favor

A small support bill shrinks the forfeit. Suppose your technology support bill is only $120,000 a year. License included would earn $250,000, but only $120,000 of it can ever be applied. BYOL earns $100,000, all of it usable, so the real forfeit is $20,000.

So model rewards at the lower of what you earn and what your support invoices can absorb within 12 months. Our Support Rewards guide works through the mechanics, and sizing the commitment itself is covered in OCI cost optimization.

Which options must you own before you can bring your own license?

You must own every option and management pack the service actually uses. This is where BYOL most often fails, because Oracle's cloud database services enable capability by service tier. You do not get to request options one at a time.

Service tiers switch features on for you

The higher tiers switch on options such as clustering, multitenant consolidation, partitioning, advanced compression, in memory processing and the Diagnostics and Tuning packs. Under license included, that is what you pay for. Under BYOL, it is what you must already hold.

• Match the tier to the licenses you hold. Selecting a high tier with only base Enterprise Edition owned creates an exposure on day one.
• Watch the packs. Diagnostics and Tuning come with even the entry Enterprise Edition tier and are often on by default. On premises they are separately licensed products.
• Check the standby. A read enabled standby uses Active Data Guard, a licensable option, and your licenses must cover both sides.
• Record the decision. Keep the tier, the license mapping and the date in one document. That document is your audit answer.

How to check what you own and what you run

• My Oracle Support. List each support identifier (CSI), the programs on it and the metric. This tells you which licenses share a license set.
• Your ordering documents. They show the net fee each support line is priced on, which is the real S in the formula.
• DBA_FEATURE_USAGE_STATISTICS. Query it on the source database to see which options and packs the workload has used before you pick a tier.
• The OCI console. Each database system shows its license type, and Cost Analysis separates BYOL and license included charges.

The double count trap

Applying a license in the cloud while the same license still runs a workload on premises is the most common finding we see on cloud audits. It looks like a saving because the cloud rate drops. On the on premises side it is a compliance gap.

Resolve it before migration. The test is simple: name the server the license came off, and name the date that server was decommissioned or repurposed. If you cannot name both, the license is not free.

The rate card is the smallest of four numbers in this decision. Support you cannot cancel, options you do not own and rewards you stop earning are the other three.

How does Exadata Cloud@Customer change the BYOL decision?

It tilts the decision toward keeping your own licenses, for reasons that have little to do with the rate card. Customers on Exadata usually own the heavy options already, and the service bundles the Exadata software you would otherwise buy separately.

What the subscription already includes, and what it commits you to

• The Exadata system software. Bundled into the infrastructure subscription, so your licenses only have to cover the database and its options.
• The hardware refresh. Priced into the term rather than run as a capital cycle you manage.
• Oracle operation of the infrastructure inside your own data center, which is usually why the service was chosen at all.
• A 4 year infrastructure term. Oracle requires the Cloud@Customer infrastructure to be subscribed for four years.
• A minimum configuration. The smallest shape sets a floor whether or not you use it, and the database service needs at least 8 ECPUs per database node.

Oracle publishes the shapes and the commercial model on the Exadata Cloud@Customer pricing page. Read the subscription term and the minimum shape before the rate, because the term commitment is the real number to negotiate.

One Support Rewards rule matters here. Oracle says the base rack subscription does not earn rewards, only the portion delivered under Universal Credits. The rack costs the same under both license models, so leave it out of the rewards comparison and count only the difference on the database ECPU line.

The metering unit changed, and many models did not

Oracle moved its Exadata and Autonomous Database services from OCPU metering to ECPU metering. Oracle defines one physical core as four ECPUs. For Autonomous Database, the published BYOL ratio is one Enterprise Edition Processor license, or 25 Named User Plus licenses, for every 8 ECPUs or 2 OCPUs.

Confirm which unit your quote is written in and use the conversion Oracle publishes for that service and metric. A comparison built on the older unit lands in the wrong place, and the error runs in whichever direction the shape pushes it. The 16 OCPU example above is 64 ECPUs on the newer unit.

Why Exadata customers usually keep their own licenses

• They own the options already. Clustering, partitioning and compression are normal on Exadata, so matching the tier is simple.
• The support is not going anywhere. The rest of the Oracle footprint keeps it alive, which sets S to zero in the crossover.
• The workloads are steady. These are not bursty systems, so the unit hours sit well above any sensible break even.
• The alternative is not public cloud. Data residency usually drove the choice, so the real comparison is with staying on premises.

More detail sits in our Exadata Cloud@Customer guide and the wider Cloud at Customer guide. For how Cloud@Customer compares with running the same databases on public OCI, see Cloud@Customer versus OCI licensing.

What have we seen in Oracle cloud license decisions in 2024 and 2025?

The rate card almost never decided the outcome. Across roughly 30 to 40 Oracle cloud cost models we built for clients in 2024 and 2025, the answer turned on what the customer could actually stop paying.

• When the license was free and the support cancellable, BYOL cut the effective compute rate by 50 to 58 percent, with a median of 54 percent.
• In roughly 4 out of 10 models, the license was still covering an on premises workload that could not be retired. Applying it in the cloud would have been a double count.
• In more than half of the remaining models, the support could not be cancelled cleanly because the licenses shared a license set with others. The plan to move those workloads to license included fell apart at that step.
• Almost none of the models we were handed had subtracted the Support Rewards given up by spending less.

Why we do not default to BYOL just because you own licenses

The usual advice is that BYOL is always cheaper, so use it whenever you hold Oracle licenses. We think that advice fails too often to be a default. In our models, the double count and the trapped support together overturned a large share of the plans, before rewards were even counted.

A lower rate card does not mean a lower invoice, and it certainly does not mean a lower bill after an audit. Start from the state of each license, run the crossover only where the support is avoidable, and default to BYOL only where the support is sunk.

What will the Oracle account team say, and how should you answer?

Expect the conversation to push toward whichever model grows your cloud commitment. These are the lines we hear most often, with the replies that keep the comparison honest.

What should you get in writing before you commit?

Get the support consequences and the model flexibility in writing before you sign the Universal Credits order or the Cloud@Customer term. A verbal assurance from the account manager does not bind Oracle at renewal or in an audit.

• A support repricing statement. A written figure for the remaining support lines if you terminate the ones you free up. Without it, the license included case is a guess.
• The right to switch models during the term. Confirmation that you can move a service between BYOL and license included without losing committed spend, so a wrong call can be fixed.
• The Support Rewards terms that apply to you. The earn rate, the eligible services and which legal entities can apply rewards, especially if you hold an unlimited agreement.
• Price holds on both rates. The BYOL and license included rates for the services you use, held for the full term, so the crossover does not move under you.
• A record of the licenses assigned to the cloud. The support identifiers and quantities you are applying, acknowledged by Oracle, so an auditor starts from the same list.
• For Cloud@Customer, the end of term options. Renewal pricing, expansion pricing and what happens to the hardware after four years.

For the platform question itself, see OCI versus AWS for Oracle workloads. If you are weighing Oracle on another cloud, the Oracle on Azure and AWS BYOL white paper covers the vCPU counting rules there.

What to do next

1. Inventory the licenses. List every license you own, the options attached to each, and the license set its support sits in.
2. Prove each license is free. For every license you plan to apply in the cloud, name the server it came off and the date it was released.
3. Ask about repricing. Ask Oracle in writing what happens to the price of the remaining support if you terminate the freed lines.
4. Get the real rate delta. Take the difference between the two models from your own quote, on the metering unit the quote is written in.
5. Run the crossover. Compute D x H against S, then check it against the hours the workload actually runs.
6. Subtract the rewards. Take off the Support Rewards you give up by spending less, capped at your technology support bill.
7. Match tier to licenses. Confirm the service tier you select only uses options you own, and record the mapping.
8. Decide per workload. Choose a model for each workload, then read our guide to bringing your own license for the mechanics of applying it.

Frequently asked questions