Oracle Autonomous Database does not use a perpetual license. It bills the ECPU hour and the terabyte, and the rate already carries the option stack you would otherwise buy line by line.
Oracle Autonomous Database is a service, not a license. It meters compute by the ECPU hour and storage by the terabyte, and the rate already carries options you would otherwise buy line by line. The buyer side questions are what is bundled, what BYOL changes, and where the bill actually lands.
Autonomous Database changes the shape of the question, not just the price. There is no processor count to defend, no core factor to argue, and no support renewal to negotiate.
What replaces all of that is a meter, a commitment, and a set of inclusions most buyers never itemise. This guide itemises them.
It is priced on consumption, drawn against a credit commitment. You pay for compute by the ECPU per hour and for storage by the terabyte per month, and there is no upfront license fee.
Oracle moved the default compute metric to ECPU on Autonomous Database for new deployments, with OCPU as the legacy metric. The published rate card sits on the Oracle Cloud price list.
Autonomous is one of three shapes Oracle sells, and choosing between them is a licensing decision as much as a technical one. The further left you sit, the more control and the more license responsibility you keep.
Three Oracle database service shapes and what each one asks of you
| Shape | Who administers it | Options position | Where the risk sits |
|---|---|---|---|
| Database on compute, self managed | You | You license every option you enable | Feature usage and processor counting |
| Base Database Service | Shared, Oracle automates the plumbing | Edition tier sets what you may use | Choosing a tier wider than the workload needs |
| Autonomous Database | Oracle | Bundled into the metered rate | Consumption, commitment shape and overage |
It includes the option stack, the management packs and the high availability features that would each carry their own line on an on premises order. That bundle is the strongest argument for the service and the one most often left out of the business case.
Price the stack you are retiring, not just the engine. A comparison built on Enterprise Edition alone understates the on premises side by a wide margin on any estate that uses options seriously.
Three things buyers routinely assume are in the rate and are not. Each of them has arrived as a variance on a real invoice we have reviewed.
Spatial and Graph is frequently listed in migration business cases as an option the service removes the cost of. It has not been separately licensed since 2019, so there is no line to remove.
Strike it from the model. A business case that claims savings that were never costs is a business case that will not survive its first review by finance.
Four meters run at once: compute in ECPU hours, storage in terabyte months, backup storage, and anything you attach around the database. Only the first two usually make it into the estimate.
ECPU is the current compute metric and OCPU is the legacy one, and the two are not interchangeable in a spreadsheet. Oracle publishes the conversion, and it is a small integer rather than the round number that circulates in secondhand material.
Take the ratio from Oracle's current documentation before you convert anything, and prefer to price directly in ECPU from the published rate card. A quote converted at a ratio someone remembered is a quote with a silent error in it.
Oracle's own cloud sits outside the authorized cloud environment list. The two vCPU rule that governs Oracle licensing on AWS and Azure does not apply on OCI, and neither does the Processor Core Factor Table.
OCI has its own conversion rules for bringing licenses across. Never reuse an AWS or Azure calculation here, and never let one be reused in the other direction.
License included bundles the software rights into the metered rate. Bring Your Own License applies Oracle Database licenses you already own and drops the rate to an infrastructure charge.
The gap between the two is visible on Oracle's published price list, so you can size it yourself without asking anyone. Read it alongside the Oracle universal credits policy.
BYOL versus license included on Autonomous Database
| Model | What you supply | What Oracle charges | Best fit |
|---|---|---|---|
| License included | Nothing | Higher ECPU rate with software bundled | Net new workloads with no owned licenses |
| BYOL, Enterprise Edition | Owned EE processor licenses in support | Lower infrastructure ECPU rate | Estates migrating owned licenses to cloud |
| BYOL, EE with options | EE plus the qualifying owned options | Lowest effective rate per ECPU | Heavy users of partitioning, security, clustering |
Oracle publishes a conversion from owned processor licenses to a permitted ECPU envelope, and the entitlement differs depending on whether you hold Enterprise Edition alone or Enterprise Edition with the qualifying options. Take that conversion from the current policy document, not from a slide.
Count the licenses you actually own and that are actually in support, map them to the envelope, and only then provision. The order of those steps is the whole control.
They spiral on auto scaling, on instances nobody stops, and on storage that only grows. Auto scaling permits compute to reach three times the base ECPU count and bills the peak by the hour.
Oracle documents the behaviour in the Autonomous Database documentation. Set a ceiling and treat it as a budget control, not a performance tuning knob.
Shape it from a measured month, never from a sales estimate. The commitment is the one term that is genuinely hard to unwind, because unused credits do not travel with you indefinitely.
Model the ceiling and the floor together, then add everything that is not compute. The floor alone is the number Oracle sales will bring you, and it is never the number that arrives.
The standard pitch is that the service removes administration cost, so the consumption rate pays for itself. We disagree, at least as a default. In roughly six out of ten estates we have modeled, the consumption bill ran 20 to 40 percent above the original estimate once auto scaling and idle non production instances were counted, and the administration saving was real but smaller than the overrun. The buyer side move is to cap auto scale, schedule non production instances to stop, settle the BYOL position, and price the option stack you are retiring before you sign any commitment. The word autonomous describes the database, not the invoice.
Sources: first two figures from the Redress Compliance advisory engagement file, 2024 to 2025. Third figure from Oracle's published auto scaling documentation.
You are not buying a license. You are buying a meter, a commitment, and a bundle. Price all three, or you have priced none of them.
Use this sequence. It works whether you are 60 days or 270 days from a commitment decision.
It is not licensed perpetually. It is metered on consumption, billed by the ECPU per hour for compute and per terabyte per month for storage, drawn against a credit commitment. Software rights are either included in the rate or supplied through Bring Your Own License.
The service bundles the option stack you would otherwise order separately, including clustering, partitioning, compression, security and the management packs. That bundle is the honest basis for comparing the service against an on premises estate, and comparing on the engine price alone understates what you are replacing.
ECPU is the current compute metric for Autonomous Database and OCPU is the legacy one. Oracle publishes the conversion between them, and you should take it from the current documentation rather than from a remembered ratio, because the wrong multiplier silently misprices a whole commitment.
Yes, where you already own Database licenses that are current on support. BYOL replaces the software portion of the metered rate with licenses you hold, and the size of the difference is published on Oracle's cloud price list so you can size it before any conversation with a rep.
No. Autonomous Data Guard is charged separately and adds a compute line for the standby, so a protected database costs materially more than an unprotected one. Model it explicitly rather than assuming resilience is part of the base rate.
The most common reason is auto scaling, which permits three times the base ECPU and bills the peak. Idle non production instances, storage that only grows, and backup retention beyond the included window account for most of the remainder.
No. Oracle's own cloud sits outside the authorized cloud environment list, so neither the Processor Core Factor Table nor the two vCPU rule used for AWS and Azure applies there. OCI has its own conversion rules, and mixing the two produces a number that is wrong in both directions.
Yes. Autonomous Database on Exadata Cloud at Customer runs the service on Oracle managed infrastructure inside your data center, which can satisfy data residency requirements while keeping the consumption model. The commercial questions in this guide apply unchanged.
Set an auto scale ceiling on each instance tied to a budget rather than to peak performance, and put budget alerts on the compartment. Schedule non production instances to stop outside working hours and review storage growth monthly.
Yes. Oracle offers an Always Free Autonomous Database tier with small fixed limits, which is useful for development, training and proof of concept work. It is not a production answer and should never appear in a capacity model.
The governance, renewal and negotiation moves that hold Oracle cost across a five year horizon.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay Oracle for the next three years.
One email a month on Oracle licensing, cloud consumption, and audit defense. Buyer side only.
