Oracle Autonomous Database licensing, explained for buyers. How ECPU billing, BYOL and the bundled options work.

Autonomous Database has no perpetual license. Oracle meters compute by the ECPU hour and storage by the terabyte, and the rate already includes options you would otherwise buy line by line. What matters is the bundle, the BYOL position and the auto scaling ceiling.

How is Oracle Autonomous Database priced?

Autonomous Database 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, with no upfront license fee.

Oracle moved the compute metric to ECPU on Autonomous Database, and the rate card sits on the Oracle Cloud price list. For scale, Oracle's own ECPU FAQ prices a 16 ECPU Lakehouse database at $5.376 an hour on the license included rate. That works out to $0.336 per ECPU hour.

Which Autonomous Database flavors can you buy?

Oracle now markets the service as Autonomous AI Database, and the console lists workload types rather than product names. The commercial logic is the same across all of them.

• Autonomous Transaction Processing. Tuned for mixed transactional and operational reporting workloads.
• Autonomous Data Warehouse. Tuned for analytics and large scan queries. The console now calls this workload type Lakehouse.
• Autonomous JSON Database. A lower cost option for document style workloads.
• Dedicated and Cloud at Customer. Isolation on Exadata infrastructure, either in Oracle's cloud or inside your own data center. Our Cloud at Customer guide covers the infrastructure contract that sits underneath.

Where does Autonomous sit against Oracle's other database services?

Autonomous is one of three shapes Oracle sells, and the choice is a licensing decision as much as a technical one. The more administration you keep, the more license responsibility you keep with it.

What does the Autonomous rate already include?

The rate 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 best argument for the service, and it is the part most often left out of the business case.

Price the whole stack you are retiring. A comparison built on Enterprise Edition alone understates the on premises side by a wide margin for any workload that uses options heavily. Our Enterprise Edition options pricing guide lists the lines you would be replacing.

Which on premises line items does the meter absorb?

• Real Application Clusters. The service runs on clustered Exadata infrastructure without a separate RAC line.
• Partitioning and Advanced Compression. Available without the separate option orders they require on premises.
• Advanced Security. Encryption at rest is on by default, and the wider data protection features come with the service.
• Multitenant. The architecture underneath is container based, and there is no separate Multitenant line to buy.
• Diagnostics and Tuning. The performance tooling is part of the service, which removes the auto use trap that costs so much on premises. Our guide to the Diagnostics and Tuning Packs covers that trap in full.
• Application Express and Oracle Machine Learning. Both are included. Check them against anything you currently run on separate infrastructure, because that infrastructure may be retirable too.

What is not included, and what does it cost to assume otherwise?

Buyers routinely assume three items are in the rate when they are not. Each has turned up as a variance on invoices we have reviewed.

• Autonomous Data Guard. The standby is a separate charge. Oracle bills it for the primary's base ECPUs plus a copy of the storage, which roughly doubles the compute line for the protected database. A cross region standby is billed at twice the primary's storage. Auto scaled ECPUs on the primary are not billed again on the standby.
• Backup storage. On the ECPU model, automatic backups are billed per GB on top of database storage, with retention set between 1 and 60 days. Long term backups are billed the same way. Backups were bundled only on the retired OCPU model.
• Data movement. Egress and any replication service such as GoldenGate sit outside the database meter entirely.

Why Spatial and Graph is not a saving

Migration business cases often list Spatial and Graph as an option the service removes the cost of. Oracle stopped licensing it separately in 2019, so there is no line to remove.

Strike it from the model. Finance will find it at the first review, and a business case that counts savings that were never costs loses credibility on every other line. The Spatial cost comparison sets out what is still chargeable.

What exactly is metered, and in what units?

Four meters run at once: compute in ECPU hours, database storage, backup storage, and the services you attach around the database. Only the first two usually make it into the first estimate.

How do ECPU and OCPU convert?

ECPU is the current compute metric. OCPU is the older one, and Oracle has now retired it as a billing metric on Autonomous Database, and OCI usage reports carry OCPU usage data only for periods before February 1, 2025. Oracle's own BYOL rules treat 8 ECPUs as equal to 2 OCPUs, which gives 4 ECPUs per OCPU.

The two metrics are not interchangeable in a spreadsheet. Take the ratio from Oracle's current documentation before you convert anything, and price directly in ECPU wherever you can. A quote converted at a ratio someone remembered carries an error that multiplies across the whole commitment.

Which metering rules decide the bill?

• Fine grained billing. ECPU usage is measured each second, averaged across the hour, with a one minute minimum. Stopping an instance does stop the compute charge.
• Storage does not stop. Allocated storage bills whether the instance is running or not. Transaction Processing storage lists at $0.1156 per GB month, so a 1 TB database carries about $118 a month of storage even when stopped. That is why stopping a non production instance saves less than teams expect.
• Storage rarely shrinks. Autonomous storage auto extends and does not contract on its own. A one off data load leaves a permanent floor until someone runs the manual shrink operation.
• The minimum is not zero. Every ECPU database needs at least 2 ECPUs, and Transaction Processing storage starts at 20 GB while Lakehouse storage is sold in 1 TB steps. A large fleet of small instances costs more than the workload suggests.
• Always Free exists and is small. The free tier allows 2 databases per tenancy, each with 20 GB of storage and 30 sessions. It suits development and proof of concept work, and it is not a production answer.

Why the AWS and Azure counting rules do not apply on OCI

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. The authorized cloud policy guide explains the rule on the other side.

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. The core factor table belongs to on premises hardware and nothing else.

What does a monthly Autonomous Database bill look like?

A realistic first month has four compute lines, and first estimates often leave out one or more of them. Take a hypothetical company with one production Transaction Processing database at 8 ECPUs, a local Autonomous Data Guard standby and three non production copies at 4 ECPUs each.

We use that license included rate and 730 hours in a month, and leave storage out.

The production base is 27 percent of this bill. The standby costs the same again, and the non production fleet costs more than production because nothing ever stops it.

Schedule the three non production instances to run 11 hours on 22 working days, which is 242 hours. Their line drops to 2,904 ECPU hours, or $975.74. That saves $1,967.62 a month and brings total compute to $5,222.78 without touching production.

What is the difference between BYOL and license included?

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.

Oracle publishes both rates, so you can size the gap before any call with a rep. The BYOL rate for Transaction Processing is $0.0807 per ECPU hour, which takes the worked example's production base from $1,962.24 to $471.29 a month. Set that against the support you keep paying on the licenses you bring.

Read the rate card alongside the Oracle universal credits service description, which carries the BYOL rules. Our BYOL versus license included comparison runs the numbers for OCI and Cloud at Customer.

How many licenses does BYOL need?

Oracle publishes the conversion from owned licenses to a permitted ECPU envelope, and it differs by edition and by the options you hold. As of this writing the rules read as follows.

• Enterprise Edition. One processor license, or 25 Named User Plus licenses, for every 8 ECPUs.
• Instances above 64 ECPUs. Real Application Clusters licenses are also required, at the same rate.
• Autonomous Data Guard used for queries or reporting. Active Data Guard licenses are required for both the primary and the standby, again one processor per 8 ECPUs. A standby kept purely for disaster recovery no longer needs them.
• Standard Edition. One processor license for every 16 ECPUs, or 10 Named User Plus licenses for every 4 ECPUs, with a hard ceiling of 32 ECPUs per instance.

Say you hold 10 Enterprise Edition processor licenses in support. That covers 80 ECPUs, or 250 Named User Plus licenses would do the same. A single 72 ECPU instance, however, crosses the 64 ECPU line and also needs 9 RAC processor licenses you may not own.

Count the licenses you actually own and that are actually in support, map them to the envelope, and only then provision. In the console you can set a BYOL ECPU limit per instance, and any usage above it is not covered by your licenses.

Which BYOL mistakes show up at the true up?

1. Double counting. The same processor license claimed on premises and on the service at the same time leaves you short on one side. Retire or repurpose the on premises deployment, and record the date. Our guide to dual running during cutover covers the migration window.
2. Support lapse. BYOL relies on licenses that are current on support. Dropping the support line to save money removes the basis for the cloud rate without anyone noticing until the next review.
3. Option mismatch. Claiming the wider BYOL entitlement without owning the qualifying options is a paper position. It does not survive a review of your ordering documents.

Where do Autonomous Database costs spiral?

Costs spiral on auto scaling, on instances left running, and on storage that only grows. With compute auto scaling on, a database can use up to three times its base ECPU count, and you pay for what it uses, averaged across each hour.

• Auto scaling left on everywhere. A base of 4 ECPUs can bill at 12 ECPUs during a runaway query or a badly timed reporting job.
• Idle instances not stopped. Non production instances left running overnight bill the full base every hour they are up.
• Storage growth. Autonomous storage auto extends and rarely shrinks without deliberate intervention.
• Cloned environments. A full clone for testing carries the parent's storage footprint, and clones outlive the test that justified them. A refreshable clone in another region bills twice the source storage.

Oracle documents the behavior in the Autonomous Database billing documentation. Treat auto scaling as a budget decision made per instance, and stop treating it as a performance setting.

Which controls should you put in place this quarter?

The 3x ceiling is fixed by Oracle, so you cannot dial it down to 1.5x. The controls you do own are the base size, the on or off switch per instance, and the rules that stop a bad query before it scales.

1. Decide per instance whether auto scaling is on, agree it with the budget holder, and record who agreed. Size the base for normal load.
2. Set runaway SQL rules on the consumer groups so a statement that passes a run time or IO limit is cancelled before it drives the instance to its ceiling.
3. Schedule non production instances to stop outside working hours, and audit the schedule monthly.
4. Set budget alerts against the compartment, not just the tenancy, so one team's overrun is visible in days rather than at month end.
5. Tag every instance with an owner and a decommission date, and enforce the date.

When do elastic pools cut the bill?

Elastic pools help when you run many small databases whose peaks do not coincide. The pool leader is billed for the pool, members are not billed for compute individually, and each member only needs 1 ECPU.

Pool capacity is four times the pool size, and billing steps with the hourly high watermark: up to the pool size, then twice the pool size, then four times. A pool sized too small for a busy hour jumps a full tier, so size it from measured peaks.

How do you check what you are actually consuming?

You check it from OCI's own billing data and the database console. These are the places to pull numbers from before any commitment conversation.

• Number of ECPUs allocated graph. On each database's console page, it shows the average ECPUs used per hour, which is the figure you are billed on. Look for hours pinned at three times the base.
• OCI Cost Analysis and cost reports. Filter by service and compartment for a full calendar month. The cost reports break usage down by resource, so you can match every line to an owner.
• Storage allocated versus used. A gap between the two is the candidate for a manual shrink.
• License type and BYOL ECPU limit. Check both on every instance against your license inventory. One instance set to license included by mistake costs the full rate until someone spots it.
• Your ordering documents. The commitment, the rate card version and any BYOL terms live there, not in the console.

Our OCI cost optimization guide covers the same checks across the rest of the tenancy.

How should the Universal Credits commitment be shaped?

Shape it from a measured month of real consumption. The commitment is the one term that is hard to unwind, because unused credits do not travel with you indefinitely.

Our guide to Oracle cloud contracts and credits covers the ordering document in full, and the Oracle CIO guide places the commitment inside a five year plan for Oracle spend.

Which rules hold up in the negotiation?

• Commit to the floor you can prove. Buy the consumption you are confident you will use, and let the rest run at the standard rate until you have evidence.
• Ask for a ramp. A commitment that steps up as the migration lands is worth more than a bigger discount on a commitment you cannot consume in year one.
• Check the support offset. Oracle Support Rewards credits 25 percent of Universal Credits consumption, or 33 percent for ULA customers, against technical support renewals. BYOL consumption on the Universal Credits rate card qualifies. Pay as you go does not. Our Support Rewards guide shows how to model it.

What contract wording should you ask for?

• A price hold on the ECPU rate. Fix the discounted rate for the full term and set the cap on any change at renewal. The price hold clause guide has sample wording.
• Overage at the committed discount. Consumption above the commitment can be charged at the standard rate unless something better is written down, so ask for your discounted rate in writing.
• Carry forward of unused credits. Get the treatment of unused credits, including any rollover period and cap, into the ordering document, and price the risk of not consuming.
• A named year by year ramp. Each year's commitment listed as a figure, tied to the migration plan.
• The BYOL rules that apply. Oracle revises the service description, so reference the version in force when you sign.

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

• "Autonomous removes your DBA cost, so the rate pays for itself." Ask them to price the auto scaling ceiling and the standby alongside the base, and compare that with the administration saving you can name by role.
• "Commit higher now and the discount goes up." Reply that you will commit to a measured month plus the migration ramp, and that the overage rate matters more to you than the headline discount.
• "License included is simpler than BYOL." Reply with your count of Enterprise Edition licenses in support and the 8 ECPU conversion, and ask for both options priced side by side.
• "Auto scaling only bills what you use." Agree, and point out that a runaway query counts as use too. Ask what they recommend for containing it, given that the 3x ceiling cannot be lowered.

What have we seen in Autonomous Database cost reviews in 2024 and 2025?

We modeled 35 Autonomous Database environments between January 2024 and December 2025. In most of them the consumption bill outran the sales estimate, and the median overrun was 28 percent once auto scaling and idle instances were counted.

• Auto scaling. Where it was left on without a budget decision, it drove 20 to 40 percent of total spend in the environments that overran.
• Non production hours. Test and development instances ran an average of 60 to 70 percent of the month when they only needed working hours.
• The missing option stack. Few teams had priced the on premises options they were retiring, so the comparison ran on the engine price alone.
• Commitments set from the estimate. In 11 engagements the annual credit commit was set from the first estimate, not from a measured month, and the shortfall was carried at pay as you go rates.

The common pitch that the DBA saving pays for the service

The standard pitch is that the service removes administration cost, so the consumption rate pays for itself. We do not accept that as a default. In roughly six out of ten environments we modeled, the bill ran between 20 and 40 percent above the estimate. The administration saving was real, but it was smaller than the overrun.

The better course is to decide auto scaling per instance, schedule non production to stop, settle the BYOL position and price the option stack you are retiring. Do all four before you sign any commitment.

You are buying a meter, a commitment and a bundle. Price all three before you sign, or the first invoice will price them for you.

How should you model total cost?

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 rarely the number that arrives.

• Base ECPU per instance across every environment, production and non production.
• Auto scaling hours estimated from the current workload profile, using peaks rather than averages.
• Storage at projected twelve month growth, plus backup storage for the retention period you actually set.
• Autonomous Data Guard where the recovery requirement demands it, priced explicitly.
• The BYOL position if you own licenses you can migrate, and the support cost of keeping them alive.
• Egress and replication, including any cross cloud egress during migration.
• The on premises stack you are actually retiring, options included, so the comparison is fair in both directions.

How does the answer change with the size of your Oracle footprint?

A company moving five or six databases usually has little to gain from BYOL and a lot to gain from scheduling and right sizing. License included keeps the paperwork simple, and the commitment should stay small until two or three months of real bills exist.

A large Oracle customer with hundreds of Enterprise Edition processors has the opposite problem. BYOL and Support Rewards drive most of the value, and the risks are double counting during migration and instances above 64 ECPUs that need RAC licenses. The negotiation there is about the ramp, the overage rate and the service description version.

What to do next

Use this sequence whether you are 60 days or 270 days from a commitment decision.

1. Measure a month. Pull a current ECPU and storage report across every instance, production and non production, for a full calendar month.
2. List what you are retiring. Itemize the on premises option stack the workload uses today, so the comparison covers the same functionality on both sides.
3. Decide auto scaling per instance. Turn it on only where a budget holder has accepted the 3x ceiling, and set runaway SQL rules everywhere it stays on.
4. Stop what is idle. Schedule non production instances to stop outside working hours and tag every instance with an owner.
5. Settle BYOL. Inventory owned Enterprise Edition and option licenses, confirm they are in support, and map them to the published ECPU envelope.
6. Add the hidden lines. Put Autonomous Data Guard, backup storage and egress into the model as explicit lines.
7. Rebuild the model. Redo the twelve month forecast with the ceiling, storage growth and the BYOL position applied.
8. Negotiate last. Only then negotiate the credits commitment, and negotiate the ramp and the overage rate alongside the headline number.

Frequently asked questions