Oracle Autonomous Database is the OCI-native database service. It is sold per ECPU or OCPU on a usage basis with optional auto-scaling. The Admodum read on the variants, the sizing model, the BYOL bridge and the renewal posture.
Autonomous Database is the OCI-native managed Oracle database service. It is sold as a fully managed offering: provisioning, patching, backup, security, and (with the autonomous features) workload tuning, query optimisation and storage management run inside the service rather than on the buyer’s operational team. The service runs on Oracle Exadata infrastructure under the hood.
The service positions Oracle as the database operator for the buyer’s OCI workloads. The buyer-side operational responsibility narrows to the application layer, the schema design, the user and role management and the data lifecycle; the database-engine operational responsibility sits with the publisher.
The wider editorial sits in the Oracle pillar and the OCI commitment context sits at the OCI commitment construct.
Autonomous Database ships in three principal variants. ATP (Autonomous Transaction Processing) is the OLTP variant, configured for mixed-workload transactional and operational reporting. ADW (Autonomous Data Warehouse) is the analytic variant, configured for columnar storage, parallel query and large-scale joins. AJD (Autonomous JSON Database) is the document variant, configured for JSON-native workloads with Oracle’s JSON optimisations.
Each variant carries a different per-OCPU or per-ECPU price and a different storage-pricing band. The buyer-side discipline runs the workload characterisation against the variant: a misallocated workload (an analytic workload on ATP, an OLTP workload on ADW) costs materially more than the well-matched variant.
Additional variants and deployment options exist (Autonomous Database on Dedicated Infrastructure, Autonomous Database on Exadata Cloud@Customer, Autonomous Database Serverless) and carry distinct commercial implications. The deeper read sits in the OCI pricing read at OCI ramp design.
Oracle has used two compute units across the OCI catalogue. The older unit is the OCPU (Oracle CPU): one OCPU corresponds, on Intel Xeon and AMD EPYC, to a physical core with hyperthreading enabled (so one OCPU is two virtual threads). The newer unit is the ECPU (Elastic CPU): one ECPU corresponds to a smaller compute slice, allowing finer-grained sizing.
The transition from OCPU to ECPU is significant for buyers because the ECPU-priced services can be sized in smaller increments. The arithmetic conversion is typically eight ECPUs per OCPU for many services; the conversion is not automatic and not always exact, and the buyer-side discipline reads the specific service’s conversion table.
The pricing arithmetic against the OCPU was the simpler buyer reading; the ECPU pricing requires more granular consumption tracking but allows tighter-fitting deployments and (for variable workloads) lower consumed cost.
The BYOL (Bring Your Own Licence) bridge allows on-premises Oracle perpetual licences to be applied against OCI consumption. The mapping is per-product: a Database Enterprise Edition Processor licence carries an OCI conversion (typically four OCPUs of Autonomous Database, subject to the Cloud Authorisation document version). The buyer pays the OCI consumption rate net of the licence credit.
The bridge is the load-bearing commercial mechanic for buyers migrating from on-prem Oracle to OCI Autonomous Database. The deeper read sits at the OCI BYOL bridge and at the Oracle cloud authorisation document.
The buyer-side discipline is to read both the on-prem position (which products, which metric, which quantity, which support fees) and the BYOL conversion (against the current Cloud Authorisation document) before committing to the OCI consumption ramp.
Autonomous Database can run with auto-scaling enabled: the database service grows its OCPU or ECPU allocation up to a ceiling (typically 3x the base allocation) as workload demand requires it, and contracts back to the base allocation when demand falls. The auto-scaling is billed against actual consumption, not against the ceiling.
The economics of auto-scaling reward variable workloads. A workload with peak demand 3x the average runs at 1.5x to 1.8x the base cost under auto-scaling (depending on the peak-duration profile), against the 3x cost of a statically-sized peak-provisioned instance. A flat workload (low variability) gains nothing from auto-scaling and is best deployed at the steady-state size.
The buyer-side discipline reads the workload profile, sets the base and the ceiling against that profile, and instruments the consumption observability so that drift (steady growth in the consumed envelope) is surfaced before the renewal moment.
Autonomous Database is consumed against the OCI Universal Credits envelope; the renewal therefore reads against the wider OCI commitment construct, not as a separate renewal event. The lever at renewal is the universal-credit commitment quantum, the tenor, the auto-scaling ceiling and any committed-use discounts.
The buyer-side discipline at renewal is the consumption read (what was consumed in the prior period, by service and by variant), the forward-demand projection (what is expected in the next period), and the BYOL position (which on-prem licences are available to bridge into the OCI consumption). The deeper read on the OCI commitment sits at the OCI commitment construct.
The wider engagement sits in the Oracle practice; the aggregated reading list sits in the Oracle knowledge hub; the renewal programme sits at renewal programme.
The wider commitment envelope Autonomous Database sits inside.
A senior Admodum Oracle advisor will read your workload profile and the BYOL bridge on a private call. Active OCI commitment events route to the Renewal Programme.