Overview

Autonomous AI Database on Dedicated Exadata Infrastructure (ADB-D) enables low‑cost, self‑service development and robust production governance in a nearly serverless model. It modernizes database estates, reduces development and operational governance costs, and provides fine‑grained control of database isolation and software change management—without requiring frequent manual actions across your database fleet.

The problem: development cost and governance complexity

Database development and enforcing robust corporate database governance can be expensive and operationally complex. Common requirements include:

– Software change management across environments (Dev → UAT → Prod)

– Strong isolation of production databases from dev/test

– Database replication to multiple physical sites for disaster recovery

With traditional cloud database services, “pay‑per‑use” typically occurs at the virtualization layer (VMs / instance classes). In practice, you pay for the VM capacity sized for peak load—even when usage is idle most of the day.

Example:

– A workload peaks for 1 hour/day at 100 cores, but is mostly idle for the other 23 hours

– You still pay for 100 cores for 24 hours because the VM/instance class is sized to the peak

To reduce these costs, organizations often adopt architectural patterns (horizontal scaling, smaller VMs, load balancers, auto‑scaling). These approaches can work for stateless application tiers, but they are not effective in the same way for databases and can add complexity.

The solution: a better pay‑per‑use model with ADB‑D

ADB‑D (available in Oracle, Azure, AWS clouds and Oracle Cloud@Customer) goes beyond traditional cloud database services with a more granular pay‑per‑use model:

– Outside of a nominal subscription reserving dedicated physical compute and storage hosts, you are not billed for CPU allocated to virtualization or container infrastructure resources

– Instead, you are billed for CPU consumed by actively running Autonomous AI Databases

– You can also create an unlimited number of completely cost‑free Developer instances

This enables “development zones” to be pre‑provisioned for self‑service with near‑zero cost until databases are actively used—true pay‑per‑use at the database rather than the VM level.

Architecture: resource model and isolation choices

ADB‑D is composed of four fundamental fully managed resource APIs:

1. Exadata Infrastructure (EI) (compute and storage servers)

2. Autonomous VM Clusters (AVM)

3. Autonomous Container Databases (ACD)

4. Autonomous AI Databases (ADB) – the primary database resource

The infrastructure, virtualization, and container layers are designed to be lightweight control APIs. All infrastructure resources are fully managed by Oracle, as an end user of the service, you do not have access to firmware, primary or guest VMs and their operating systems. The service infrastructure APIs let you:

– Expand capacity

– Control isolation boundaries

– Establish an autonomously enforced operational governance model

These APIs are typically used infrequently—for example:

– Exadata Infrastructure might be provisioned once and not changed for years

– VM Clusters and Containers might only be created when onboarding new application teams, then used for years

Isolation is fully configurable

You control the isolation level based on database criticality, with patterns such as:

– Shared development model: 

  Create one large Autonomous VM Cluster covering a single Exadata Infrastructure and assign teams quotas for development in a shared environment.

– Maximum isolation for mission‑critical production: 

  Provide a single mission‑critical production database with its own Exadata system, with a single Autonomous VM Cluster and Autonomous Container hosting only that one database.

Hands‑free software change management (Dev → UAT → Prod)

ADB‑D supports policy‑based governance across infrastructure resources so software change management can run without constant manual intervention.

You can define update policies such as:

– Dev/Test always updates to the latest available release

– UAT lags Dev/Test by one software release

– Production lags UAT by 30 days

These controls are available per Autonomous Container Database, not as a single global switch for the entire Exadata Infrastructure. This enables each application team to manage its own update cycle while still following enterprise governance requirements.

Access, quotas, and self‑service at scale

ADB‑D includes a quota and access management model so application teams can:

– View only the environments they are permitted to access

– Self‑service within an assigned CPU quota

Example:

– Team A gets a 10‑core quota in an isolated environment

– Team B gets a 100‑core quota in another isolated environment

– Both can also be granted quota/access to a shared development environment

After initial infrastructure setup, you effectively have a personal serverless database platform—running for a single customer on a completely dedicated infrastructure stack.

Key takeaway

ADB‑D is a strong approach to modernize database estates, lower development and governance costs, and implement robust, fine‑grained software change management—while keeping a nearly serverless user experience for teams.

Resources

Documentation, Autonomous AI Database on Dedicated Exadata Infrastructure.

Zero to low cost Developer Databases using Autonomous AI Database

Software change management on Autonomous AI Database on Dedicated Exadata Infrastructure