Introduction to Oracle Autonomous Database

Oracle Autonomous Database (ADB) represents a fundamental shift in how organisations deploy enterprise databases in the cloud. Unlike traditional self-managed database installations, ADB removes the operational overhead of database administration through comprehensive AI-driven automation. The service handles tuning, security patching, backups, scaling, and failover without manual intervention, allowing IT teams to focus on application development and business logic rather than infrastructure maintenance.

ADB is available in two primary configurations: Autonomous Transaction Processing (ATP) optimised for OLTP workloads, and Autonomous Data Warehouse (ADW) designed for analytical workloads and reporting. Both share the same underlying Exadata infrastructure and licensing model, but differ in performance characteristics and pricing.

The ECPU Billing Metric: What Changed

In January 2024, Oracle retired the OCPU (Oracle Compute Processing Unit) billing metric for Autonomous Database, replacing it with ECPU (Elastic Compute Processing Unit). This change was significant because ECPU provides more granular, flexible scaling compared to the previous model. The minimum configuration for any ADB instance is now 2 ECPUs, with the ability to scale upward in 1 ECPU increments up to limits determined by the database edition and licensing model.

"In one engagement, an APAC retail enterprise evaluating Autonomous Database for a mission-critical ERP workload had been quoted License-Included pricing. Redress Compliance modelled BYOL vs License-Included over three years, identifying a $920,000 saving. The analysis directly influenced the contract negotiation."

ECPU autoscaling is a critical feature: a database provisioned with a baseline of 4 ECPUs can automatically burst to 12 ECPUs (3x the provisioned capacity) during peak demand periods. This elasticity is particularly valuable for unpredictable workloads where peak consumption would otherwise require expensive over-provisioning. The autoscaling feature is enabled by default, and charges apply only to the peak usage consumed, not the baseline.

License-Included vs. BYOL: Two Fundamentally Different Approaches

Oracle offers two licensing models for Autonomous Database, and selecting the right one is critical for cost optimisation and compliance.

License-Included Model

The License-Included model bundles the Oracle Database license into the hourly ECPU rate. This approach is attractive for organisations without existing Oracle Database licences, teams deploying development and test workloads, or scenarios where flexibility matters more than minimising cost. There are no upfront licence commitment requirements, and you pay only for what you consume on an hourly basis. The simplicity of this model appeals to teams new to Oracle Database, as there is no need to track licence entitlements, verify licence eligibility, or navigate the complexity of licence metric conversion.

The trade-off is cost: License-Included pricing is substantially higher than BYOL pricing because Oracle includes the full database licence cost in the ECPU rate. Over a multi-year horizon, especially for production workloads, the accumulated cost difference becomes significant.

BYOL (Bring Your Own Licence)

BYOL allows organisations to apply existing on-premise Oracle Database licences to Autonomous Database deployments, reducing ECPU costs by approximately 76%. This dramatic cost reduction makes BYOL the preferred model for organisations with unused or under-utilised Oracle Database licences, particularly Enterprise Edition licences. BYOL requires that organisations hold valid licences that are not currently deployed on other systems simultaneously—a critical compliance requirement.

The prerequisites for successful BYOL deployment are strict: you must possess Enterprise Edition or Standard Edition 2 licences with active Oracle Software Update Licence and Support (SULS). Your licences must not be in active use on any other system, whether on-premise or in the cloud. This restriction exists because licence metrics are based on the actual infrastructure where the licence is deployed.

Understanding ECPU-to-Licence Conversion

For organisations implementing BYOL on ADB, the conversion between ECPUs and processor licences is fixed: one Oracle Enterprise Edition processor licence covers up to 8 ECPUs for both ATP and ADW deployments. This ratio is favourable compared to other cloud deployment models, allowing organisations to deploy databases with meaningful capacity under limited licence entitlements.

Standard Edition 2 BYOL deployments operate under different constraints. SE2 is capped at 16 ECPUs per ADB instance. This is a hard limit imposed by Oracle—if your workload requires more than 16 ECPUs, you must use Enterprise Edition licences. Additionally, SE2 licences are subject to a 2-socket limitation on-premise, which translates to specific constraints in cloud deployments. Understanding these limits early in your procurement process prevents costly reconfigurations later.

Serverless vs. Dedicated Deployment Models

ADB operates in two deployment modes, each with distinct operational and compliance implications.

Serverless Deployment

Serverless ADB runs on shared Oracle Exadata infrastructure managed entirely by Oracle. The service is elastic by design: your database automatically scales to meet demand, Oracle manages all infrastructure patching and failover, and billing is based solely on the ECPUs you consume. For development and test environments, ADB includes an auto-pause feature that suspends the database after a period of inactivity, effectively reducing billing to near-zero for idle databases. The minimum billing is 2 ECPUs per instance, which suits most use cases and provides a low cost of entry for exploratory workloads.

Serverless is ideal for organisations that value operational simplicity, variable workloads, and minimal upfront infrastructure investment. However, serverless databases share Exadata hardware with other customer deployments, which may present concerns for organisations with strict data isolation or compliance requirements.

Dedicated Deployment

Dedicated ADB runs on Exadata infrastructure provisioned exclusively for your organisation. Deployment options include Exadata Cloud@Customer (located in your data centre under your physical control) or dedicated Exadata in Oracle data centres (full isolation, Oracle-managed infrastructure). Dedicated deployment eliminates resource contention with other customers and provides greater control over the underlying hardware, network, and security posture.

Dedicated ADB is mandatory for organisations subject to strict data residency regulations, high-security compliance frameworks (such as healthcare or financial services standards), or government sector requirements. The higher base cost of dedicated infrastructure is often justified by compliance mandates and the elimination of shared-tenant risk.

Elastic Pools: Multiplying Cost Efficiency

Elastic Pools represent one of the most underutilised cost optimisation features for ADB. Multiple ADB instances can share a pool of ECPUs, allowing workloads that don't peak simultaneously to draw from a shared reserve. For example, if you operate a transaction processing database (ATP) that peaks during business hours and a data warehouse (ADW) that runs intensive jobs at night, those two databases can share a single ECPU pool and consume capacity as needed.

Oracle states that organisations using Elastic Pools can achieve up to 87% compute cost savings compared to provisioning ECPUs independently per database. This dramatic savings potential justifies architectural review and potential database consolidation during migration planning. However, Elastic Pools introduce operational complexity: they require careful resource forecasting and monitoring to ensure that peak demand from one workload doesn't starve another. Cost savings should be weighed against the operational overhead of managing shared capacity.

Practical Cost Optimisation Checklist

Reducing ADB costs requires systematic attention across multiple dimensions:

  • Leverage BYOL if available: If your organisation holds unused Enterprise Edition licences, BYOL should be your default. The 76% cost reduction is transformative.
  • Minimise base ECPU allocation: Provision the absolute minimum ECPUs required and rely on autoscaling for peak demand. A conservative baseline reduces your fixed cost footprint.
  • Use auto-pause for development and test: Enable auto-pause on non-production databases to eliminate billing during idle periods. This can reduce development environment costs by 70-90%.
  • Implement Elastic Pools for compatible workloads: Review your database portfolio and identify workloads that can safely share capacity. Even modest pooling arrangements yield significant savings.
  • Right-size storage allocation: Storage is billed separately from compute. Review your actual storage utilisation and adjust provisioned storage accordingly; unnecessary storage adds to your bill every month.
  • Negotiate Universal Credits arrangements: If you plan sustained ADB usage, negotiate Universal Service Agreements (UCA) or other commitment-based pricing with Oracle. Per-unit rates on committed contracts are substantially lower than pay-as-you-go pricing.

Common Licensing Mistakes to Avoid

In our experience advising organisations on Oracle Autonomous Database licensing, we observe recurring mistakes that organisations can avoid with proper planning:

Running License-Included when BYOL licences are available: We encounter organisations deploying ADB with License-Included pricing while holding dormant Enterprise Edition licences from discontinued on-premise systems. This represents a fundamental mismatch—applying those licences to ADB immediately reduces costs by 76%.

Failing to verify licence eligibility: Some organisations assume that licences purchased years ago are eligible for BYOL without confirming active SULS status or current entitlements. Licensing eligibility requires formal verification from Oracle. Procure this verification early in your cloud planning to avoid deployment delays.

Using Standard Edition 2 BYOL for large workloads: SE2 is capped at 16 ECPUs per instance. We see organisations provisioning SE2 BYOL, discovering the workload requires more capacity, and then incurring the cost and operational disruption of migrating to Enterprise Edition. Forecast your ECPU requirements before committing to SE2.

Over-provisioning ECPUs without autoscaling: Some teams provision 20, 30, or 40 ECPUs statically without enabling autoscaling, paying for unused capacity month after month. Autoscaling is enabled by default—use it.

Support Costs: A Hidden Component of BYOL

BYOL is not "free"—this is a critical distinction many organisations overlook. If you deploy on-premise licences to ADB via BYOL, you must maintain active Oracle Software Update Licence and Support (SULS) for those licences. Oracle support fees increase 8% per year, compounding over the contract term. A 10-year BYOL arrangement with 8% annual support escalation results in cumulative support costs that are substantial.

For a 10-licence Enterprise Edition deployment, if support begins at USD 40,000 annually, by year 10 annual support costs exceed USD 86,000. Multiply this across a large licence portfolio and the impact is significant. Organisations evaluating BYOL vs. License-Included must model the full cost of support escalation, not just the upfront ECPU savings. In some scenarios—particularly for smaller deployments or short-term projects—License-Included may prove more cost-effective when support escalation is factored in.

How Redress Helps With ADB Licensing

Redress Compliance specialises in independent Oracle cloud licensing advisory, working exclusively on the buy-side to protect your interests. Our team brings 20+ years of experience navigating Oracle licensing complexity across Autonomous Database and other cloud services. We help organisations in three key areas:

First, we conduct comprehensive reviews of your existing licence estate to identify BYOL opportunities and quantify the cost savings potential. We validate that licences are genuinely unused and eligible for ADB deployment, eliminating the risk of compliance violations.

Second, we assist with cost modelling and contract negotiation. We help you understand whether BYOL or License-Included is optimal for your specific workload mix, and we structure ADB procurement agreements to include price caps and service level commitments that protect your interests.

Third, we provide ongoing advisory as your ADB footprint evolves. Database requirements change, workloads grow, and licensing optimisation opportunities emerge. We monitor your deployment and flag opportunities for cost reduction or licence rebalancing.

Need help optimising your Oracle Autonomous Database licensing?

Our independent advisors can validate your cost model and identify savings opportunities.
Speak to an Expert →