Oracle Autonomous AI Database Serverless Features Billing

Shows billing information for Autonomous AI Database features for ECPU and OCPU billing models.

ECPU Compute Model

• Automatic Backups: The storage for backups is billed, per GB, in addition to your selected database storage.

  For example, if backups are occupying 200 GB of storage you are billed for 200 GB of backup storage (in addition to the usage billed for your selected number of ECPUs and database storage). See ECPU Compute Model Billing Information for more detail about which SKUs are billed for backups.

• Long-Term Backups: The storage for long-term backups is billed, per GB, as backup storage, in addition to your database storage.

  For example, if automatic backups are currently occupying 200 GB and long-term backups are occupying 600 GB of storage, you are billed for 800 GB of backup storage, in addition to the usage billed for your selected ECPUs and database storage. See ECPU Compute Model Billing Information for more detail about which SKUs are billed for each workload type and backups.

• Compute auto scaling: When compute auto scaling is enabled, your database may use and you may be billed for additional ECPU consumption as needed by your workload, up to three times (3x) the number of base ECPUs, as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

  • Your billed ECPU usage per hour while your database is running is based on the base number of ECPUs you selected for your database, plus any additional ECPU usage due to auto scaling.

  • A stopped Autonomous AI Database instance has zero ECPU usage.

  • ECPU usage is measured each second, in units of whole ECPUs and averaged across an hour. If your database is running for less than an hour or auto scales for only part of an hour, it is billed per second for the average ECPU consumption, over the base ECPUs, during that hour. The minimum ECPU consumption is one minute.

  For example, if your database has ECPU count 4 with Compute auto scaling enabled:

  • Assume in hour one your database is Available for the entire hour and ECPU utilization is under 4 ECPUs. Your database will be billed for 4 ECPUs.

  • Assume in hour two your database is Available for the entire hour and ECPU utilization is under 4 ECPUs for 30 minutes, 50% of the hour, and auto scales to 8 ECPUs for 30 minutes (the other 50% of the hour). The usage for this period, for billing, is 6 ECPUs (based on the average per-second ECPU usage for hour two).

• Storage auto scaling:

  • For storage usage under your reserved base storage, you are billed based on your base storage.

  • After your allocated storage exceeds your reserved base storage, storage usage is billed based on your allocated storage rounded up to the nearest TB, in a given hour.

  For example, if your reserved base storage is 4 TB, until your allocated storage exceeds 4 TB of storage, you are billed based on your base storage (4 TB). After you exceed 4 TB, storage is billed based on the allocated storage rounded up to the nearest TB, in a given hour. In this example, if the allocated storage grows over 4 TB in a given hour, say to 4.9 TB, you are billed for 5 TB of storage from that hour onward.

  If you then delete 1 TB of data, your allocated storage remains at 4.9 TB and you are billed for 5 TB until you perform a shrink operation. When you perform a shrink operation, may be able to shrink /reduce your allocated storage back to 3.9 TB. After the shrink operation completes and your allocated storage (3.9 TB) is once again under your reserved base storage (4 TB), you will once again be billed for your reserved base storage of 4 TB. See Shrink Storage for more information.

• Autonomous Data Guard Standby – Local (Same-Region)

  Local Autonomous Data Guard peer databases incur the additional cost of the base ECPUs and the storage of the Primary database, including any auto scaled storage usage, billed on the Primary database itself. auto scaled ECPUs of the Primary database are not billed for additionally on the local Autonomous Data Guard peer database. The number of base ECPUs is specified by the number of ECPUs as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

  For example, if you enable a local Autonomous Data Guard peer on a source database with:

  • 2 (base) ECPUs with Compute auto scaling enabled and are consuming about 4 ECPUs per hour

  • 1 TB of (base) storage with storage auto scaling, consuming a total of 2 TB of database storage

  For the local Autonomous Data Guard peer you are billed for an additional 2 ECPUs (your base ECPU selection), plus an additional 2 TB of storage (that is, the same amount of storage reserved for the source Primary with auto scale, on the Primary database).

  When the Primary database is stopped, neither the primary nor the peer database is billed for ECPU.

• Autonomous Data Guard Standby - Remote (Cross Region)

  Autonomous Data Guard cross region peer databases incur the additional cost of the base ECPUs and twice (2x) the storage of the Primary database, including any auto scaled storage usage, billed on the remote peer database. auto scaled ECPUs of the Primary are not billed for additionally on the remote peer database. The number of base ECPUs is specified by the number of ECPUs as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

  For example, if you enable a cross region Autonomous Data Guard peer for a source database with:

  • 2 (base) ECPUs with Compute auto scaling enabled and are consuming about 4 ECPUs per hour

  • 1 TB of (base) storage with storage auto scaling, consuming a total of 2 TB of database storage

  For the cross region Autonomous Data Guard peer you are billed an additional 2 ECPUs (your base ECPU selection), plus 4 TB of storage (that is 2x the storage reserved for the source Primary with auto scaling, billed on the remote peer database).

  When the Primary database is stopped, neither the primary nor the peer database are billed for ECPU.

  When the option Enable cross region backup replication to disaster recovery peer is selected, you are billed for twice (2x) the backup storage size required for the replicated backups, billed to the remote standby.

  When a cross region peer operates as a Snapshot standby, the Snapshot standby CPU usage is billed based on the base CPU count and any additional CPU usage if compute auto scaling is enabled. The number of base CPUs is specified by the number of ECPUs as shown in the ECPU count field on the Oracle Cloud Infrastructure Console.

• Backup-Based Disaster Recovery – Local (Same-Region) Backup Copies There are no additional costs for local Backup-Based Disaster Recovery, other than the cost of storage for automatic backups.

• Backup-Based Disaster Recovery – Remote (Cross Region) Backup Copies Billing for a cross region Backup-Based Disaster Recovery is twice (2x) the amount of backup storage required for the replicated cross region backups, billed to the remote peer.

  For example, if you enable a cross region backup copy on a source database with:

  • 2 (base) ECPUs

  • 2 TB of database storage

  If the backups replicated to the remote region take up 1.9 TB of storage, you will be billed for 3.8 TB of backup storage on the remote backup copy peer database.

  When the option Enable cross region backup replication to disaster recovery peer is selected, you are billed for twice (2x) the amount of backup storage size required for the additional replicated backups, billed to the remote peer. This billing is based on the number of days set for the backup retention on the Primary, as follows:

  • When automatic backup retention is set to 7 days or greater, billing is based on the storage size for 7 days of replicated backups.

  • When automatic backup retention is set to less than 7 days, billing is based on the storage size for the specified number of days of data that is replicated to the cross region standby.

• Refreshable Clone Local (Same-Region) Local refreshable clones have their own configurable ECPU selection, and so they are billed for ECPU based on the user-selected number of ECPUs, with or without auto scaling; they do not get billed additionally over the ECPU selection. The number of ECPUs is specified by the number of ECPUs as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

  Local refreshable clones are billed for the same amount of storage as their source database.

  For example, if you create a 2 ECPU local refreshable clone from a source database with:

  • 4 ECPUs

  • 1 TB of storage with storage auto scaling and consuming 2 TB of storage

  For the local refreshable clone you will be billed for 2 ECPUs, that is, the refreshable clone's ECPU count value, and 2 TB of storage (that is, the storage reserved for the source database).

  When you start or stop the source database, your actions on the source database do not affect the refreshable clone. A refreshable clone is started or stopped independently of the source database.

• Refreshable Clone Remote (Cross Region) Remote refreshable clones have their own configurable ECPU selection, and so they are billed for ECPU based on the user-selected ECPU (with or without auto scaling); they do not get billed additionally over the ECPU selection. The number of ECPUs is specified by the number of ECPUs as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

  Remote refreshable clones are billed for twice (2x) the amount of storage as their source database.

  For example, if you create a 2 ECPU remote refreshable clone from a source database with:

  • 4 ECPUs

  • 1 TB of storage with storage auto scaling and consuming 2 TB of storage

  For the remote refreshable clone you are billed for 2 ECPUs (that is, the refreshable clone's ECPU selection) and 4 TB of storage (that is, 2x the storage reserved for the source database)

  Starting or stopping the source database does not affect the refreshable clone - The refreshable clone can be started or stopped independently.

• Snapshot Standby for Remote (Cross Region) Disaster Recovery

  Snapshot standby ECPU usage is billed based on the base ECPU count and any additional ECPU usage if compute auto scaling is enabled. The number of base ECPUs is specified by the number of ECPUs, as shown in the ECPU count on the Oracle Cloud Infrastructure Console.

  Snapshot standby storage usage is billed based on the storage of the snapshot standby plus (1x) the storage of the source primary database.

  For example, if you have a 2 ECPU and 3 TB snapshot standby from a source database with:

  • 4 ECPUs

  • 1 TB of storage with storage auto scaling and consuming 2 TB of storage

  Your snapshot standby will be billed for 2 ECPUs (that is, the snapshot standby's ECPU selection) and 3 TB + 2 TB = 5 TB of database storage (that is, the storage reserved on the snapshot standby + the storage reserved on its source database)

• Elastic Pools: An elastic pool allows you to provision 4 times the ECPU count that you have as your pool size. For example, if you have a pool with pool size of 128 ECPUs, you can provision up to 512 ECPUs in this pool. In other words, when your pool size is 128 ECPUs, your pool capacity is four times the pool size (in this example, 512 ECPUs).

  Databases that belong to a pool are not billed individually for compute. The compute billing for all the pool members and the leader happens through the leader. In other words, individual members of an elastic pool do not get billed for compute as long as they are part of the pool. This applies no matter what the workload type is for the pool member. For example, when a pool member with workload type Lakehouse is added to a pool, it's compute usage is billed to the pool leader at the Transaction Processing compute usage rate. The storage billing, on the other hand, continues to be billed to individual Autonomous AI Database instances irrespective of them being part of a pool or not.

  Let’s assume you have an elastic pool with pool size of 128 ECPUs. Given the pool size, the pool capacity is 512 ECPUs (pool capacity = 4x pool size). For this sample, here are some common billing questions and answers:

  • What is the maximum number of Autonomous AI Database instances allowed in this pool? A total of 512 Autonomous AI Database instances with 1 ECPU each (elastic pool members or the leader can have an individual ECPU allocation as low as 1 ECPU).

  • What happens if the aggregated ECPU utilization high watermark of the pool is greater than the pool size? If the aggregated ECPU utilization high watermark is less than or equal to the pool size in a given billing hour, the hourly charge is in the amount of the pool size. If the aggregated ECPU utilization high watermark is more than the pool size but less than or equal to the 2x pool size in a given billing hour, the hourly charge is in the amount of 2x pool size. If the aggregated ECPU utilization high watermark is more than 2x pool size in a given billing hour, the hourly charge is in the amount of 4x pool size.

    For example, let’s assume 512 Autonomous AI Database instances with 1 ECPU each are in an elastic pool with a pool size of 128 ECPUs. If the aggregated ECPU utilization high watermark of these databases is 100 ECPUs between 1pm-2pm, and 250 ECPUs between 2pm-3pm; then the billing is 128 ECPU hours between 1pm-2pm and 256 ECPU hours between 2pm-3pm.

  See Autonomous AI Database Elastic Pool Billing for more information.

• Undelete an Autonomous AI Database Instance

  If you undelete an Autonomous AI Database instance, in the first hour after the undelete operation you are billed for the base CPU and Storage, including database storage and long term backups, for the total time when the database was deleted, as if the database was never deleted and was running.

  For example, if you terminate an Autonomous AI Database instance with:

  • 4 ECPU with Compute auto scaling enabled

  • 2 TB Storage, with 100 GB of automatic backup storage and 20 GB of long-term backup storage

  If after 5 hours and 30 minutes you undelete the terminated instance, in the first hour after the undelete operation the billing includes the additional costs as if the database was never deleted and was running, including:

  • 5 hours and 30 minutes for the base 4 ECPUs

  • 2 TB Storage

  • 100 GB of automatic backup storage

  • 20 GB of long-term backup storage

• Scheduled Upgrade to 26ai

  When you schedule an upgrade for an Autonomous AI Database instance there are two choices for the upgrade type:

  • Earliest available schedule: This upgrade option incurs no additional charges.

  • Future schedule: When you schedule an upgrade with a future schedule, additional resources are immediately spun off for the database and its attached clones or standbys, which are billed as follows:

    • You are billed for the additional cost of the base ECPUs and the storage of the source Autonomous AI Database instance.

    • You are billed for the additional cost of the base ECPUs and the database storage for each attached local and remote refreshable clone.

    • You are billed for the additional cost of the base ECPUs and the database storage for each local and remote Autonomous Data Guard standby database.

    For example, if you choose to upgrade your database and you select Future schedule with a schedule 30 days in the future, on an Autonomous AI Database instance with the following configuration:

    • 4 ECPUs with Compute auto scaling enabled

    • 1 TB storage

    • 1 refreshable clone

    • 1 remote Autonomous Data Guard Standby

    You are billed as follows:

    Twice (2x) for the base ECPUs and 2x for the database storage for 30 days until the upgrade is completed:

    4 + 4 = 8 ECPUs

    1 + 1 = 2TB database storage

    Additionally, you are billed twice (2x) for the base ECPUs and the storage on the attached refreshable clone and the remote Autonomous Data Guard standby, for 30 days until the upgrade is completed.

    For upgrades involving elastic pool members or an elastic pool leader, with an upgrade of type Future schedule:

    • The billing for either a member or the leader, if either one schedules an upgrade: the database's base CPU usage is billed 2x to the leader's database OCID.

    • The billing for the storage usage for a member with a scheduled upgrade is billed 2x directly to the member's database OCID, separate from any storage amounts reported for billing on the pool leader.

    • The storage usage for the leader with a scheduled upgrade is billed 2x directly to the leader's database OCID.

    You do not incur charges for canceling a scheduled upgrade. However, the charges that were billed between the time you scheduled the upgrade and the time that you canceled the upgrade remain.

• Oracle Autonomous AI Database API for DynamoDB

  DynamoDB-compatible tables are charged using a provisioned throughput capacity model. This represents the amount of reads and writes that the table can support. You are billed based on the specified throughput capacity, not actual usage. Provisioned Read Capacity Units (RCUs) and Write Capacity Units (WCUs) are internally mapped to the required number of ECPUs to support the specified capacity. The ECPU mapping is always done with auto-scaling enable and cannot be changed to allow for workload peaks without impact on your application. Autoscaling billing is identical to the Autoscaling capabilities of Autonomous AI Database. The corresponding ECPU usage is billed against the Autonomous AI Database in which the DynamoDB API feature is enabled.

  • Storage: You are billed at the same price as adb_tp (ATP) Storage for storage, with Part Number B95706 (Oracle Autonomous AI Database Storage for Transaction Processing)

  • ECPUs: You are billed at Oracle adb_tp – ECPU – BYOL price with Part Number B95704.

  RCUs and WCUs are internally mapped to ECPUs as follows:

  • 125 RCUs (Read Capacity Units) = 1 ECPU

  • 75 WCUs (Write Capacity Units) = 1 ECPU

  • A minimum of 2 ECPUs is allocated per table. Fractional ECPU amounts are rounded up to the next whole number.

  • Read Capacity Unit (RCU): A strongly consistent read request of up to 4 KB per second consumes one RCU. For items larger than 4 KB, additional RCUs are required.

  • Write Capacity Unit (WCU): A standard write request of up to 1 KB per second requires one WCU. For items larger than 1 KB, additional WCUs are required.

  Example calculation:

  • Provisioned: 200 RCUs and 120 WCUs

  • ECPUs = Round up (200/125 + 120/75) = Round up (1.6 + 1.6) = 4 ECPUs allocated

  Example billing:

  The following illustrates how Oracle enforces a minimum of 2 provisioned ECPUs per DynamoDB table and how the usage of autoscale ECPUs impacts the billing. In the following scenario, the RCU and WCU requirements and ECPU usage for Table 1 are below the required minimum. You will be charged the minimum of 2 provisioned ECPUs. Table 2, however is using more RCUs and WCUs than specified and mapped to 2 ECPUs, meaning that Table 2 leveraged auto-scaling capabilities and incurred a usage or 3 ECPUs. It will be therefore billed for 3 ECPUs.

  • Table 1: Base = 2 ECPUs, Usage = 1 ECPU → 2 ECPUs billed

  • Table 2: Base = 2 ECPUs, Usage = 3 ECPUs → 3 ECPUs billed

  • Total ECPUs billed: 5 ECPUs

  • Total storage billed: Sum of actual storage usage across all tables (for example, 10 GB + 10 GB = 20 GB)

OCPU Compute Model

• Automatic Backups: The storage for automatic backups is included in the cost of database storage. See OCPU Compute Model Billing Information for more detail about which SKUs for database storage.

• Long-Term Backups: The storage for long-term backups is billed per TB as additional database storage, in addition to your selected database storage usage.

  For example, if automatic backups occupy 200 GB and long-term backups occupy 600 GB of storage, you will be billed for 1 TB (600 GB of long-term backup storage rounded up to the nearest TB) as database storage, in addition to the usage billed for your selected OCPU and database storage. See OCPU Compute Model Billing Information for more detail about which SKUs are billed for each workload type and backups.

• Compute auto scaling: When compute auto scaling is enabled your database may use and you may be billed for additional OCPU consumption as needed by your workload, up to three times (3x) the number of base OCPUs (as shown in OCPU count on the Oracle Cloud Infrastructure Console)

  • Your billed OCPU usage per hour while your database is running is based on the base number of OCPUs you selected for your database, plus any additional OCPU usage due to auto scaling.

  • A stopped Autonomous AI Database instance has zero OCPU usage.

  • OCPU usage is measured each second, in units of whole OCPUs and averaged across an hour. If your database is running for less than an hour or auto scales for only part of an hour, it will be billed per second for the average OCPU consumption (over the base OCPU) during that hour. The minimum OCPU consumption is one minute.

• Storage auto scaling:

  • For storage usage under your reserved base storage, you are billed based on your base storage.

  • After your allocated storage exceeds your reserved base storage, storage usage is billed based on your allocated storage rounded up to the nearest TB, in a given hour.

  For example, if your reserved base storage is 4 TB, until your allocated storage exceeds 4 TB of storage, you are billed based on your base storage (4 TB). After you exceed 4 TB, storage is billed based on the allocated storage rounded up to the nearest TB, in a given hour. In this example, if the allocated storage grows over 4 TB in a given hour, say to 4.9 TB, you are billed for 5 TB of storage from that hour onward.

  If you then delete 1 TB of data, your allocated storage remains at 4.9 TB and you are billed for 5 TB until you perform a shrink operation. When you perform a shrink operation, Autonomous AI Database may be able to shrink / reduce your allocated storage back to 3.9 TB. After the shrink operation completes and your allocated storage (3.9TB) is once again under your reserved base storage (4 TB), you will once again be billed for your reserved base storage of 4 TB. See Shrink Storage for more information.

• Autonomous Data Guard Standby Local (same-region)

  Local Autonomous Data Guard peer databases incur the additional cost of the base OCPUs and the storage of the Primary database, including any auto scaled storage usage, billed on the Primary database itself. auto scaled OCPUs of the Primary database are not billed for additionally on the local Autonomous Data Guard peer database. The number of base OCPUs is specified by the number of OCPUs, as shown in the OCPU count on the Oracle Cloud Infrastructure Console.

  When the Primary database is stopped, neither the primary nor the peer database is billed for OCPU.

• Autonomous Data Guard Standby Remote (Cross Region)

  Autonomous Data Guard cross region standby databases incur the additional cost of the base OCPUs and twice (2x) the storage of the Primary database, including any auto scaled storage usage, billed on the remote peer database. auto scaled OCPUs of the Primary are not billed for additionally on the remote peer database. The number of base OCPUs is specified by the number of OCPUs, as shown in OCPU count on the Oracle Cloud Infrastructure Console.

  When the Primary database is stopped, neither the primary nor the peer database is billed for OCPU.

  When the option Enable cross region backup replication to disaster recovery peer is selected, you are billed to the remote standby database's OCPU database storage, for twice (2x) the 7 day replicated backup storage size, rounded up to the nearest TB.

• Backup-based Disaster Recovery Local (same-region) Backup Copies There are no additional costs for local Backup-Based Disaster Recovery, other than the cost of keeping automatic backups.

• Backup-Based Disaster Recovery Remote (Cross Region) Backup Copies

  Billing for a cross region Backup-Based Disaster Recovery with OCPUs is twice (2x) the amount of storage required for backups replicated to the remote region, billed as database storage to the remote peer, rounded up to the nearest TB.

  When the option Enable cross region backup replication to disaster recovery peer is selected, you are billed to the remote peer database's OCPU database storage, for twice (2x) the replicated backup storage size, rounded up to the nearest TB.

• Refreshable Clone Local (same-region)

  Local refreshable clones have their own configurable OCPU selection, and so they are billed for OCPU based on the user-selected OCPU (with or without auto scaling); they do not get billed additionally over the OCPU selection. The number of OCPUs is specified by the number OCPUs as shown in the OCPU count on the Oracle Cloud Infrastructure Console.

  Local refreshable clones are billed for the same amount of storage as their source database.

  Starting or stopping the source database does not affect the refreshable clone. The refreshable clone can be started or stopped independently.

• Refreshable Clone Remote (Cross Region)

  Remote refreshable clones have their own configurable OCPU selection, and so they are billed for OCPU based on the user-selected OCPU (with or without auto scaling); they do not get billed additionally over the OCPU selection. The number of OCPUs is specified by the number of OCPUs as shown in the OCPU count on the Oracle Cloud Infrastructure Console.

  Remote refreshable clones are billed for twice (2x) the amount of storage as their source database.

  Starting or stopping the source database does not affect the refreshable clone. The refreshable clone can be started or stopped independently.

• Snapshot Standby for Remote (Cross Region) disaster recovery

  Snapshot standby OCPU usage is billed based on the base OCPU count and any additional OCPU usage if compute auto scaling is enabled. The number of base OCPUs is specified by the OCPUs as shown in the OCPU count on the Oracle Cloud Infrastructure Console.

  Snapshot standby storage usage is billed based on the storage of the snapshot standby plus (1x) the storage of the source primary database.