How to Achieve up to 87% Compute Cost Savings with Elastic Pools on Autonomous Database

September 19, 2023 | 4 minute read
Can Tuzla
Principal Product Manager
Text Size 100%:

Many organizations resort to database consolidation nowadays to reduce infrastructure and operational costs, and this is often achieved by allocating more resources to each database than the infrastructure can physically offer based on the assumption that the consolidated databases will not experience simultaneous peak demands for those resources. When customers decide to move these databases from their on-premises data centers (or other platforms) to Autonomous Database, they rightfully want to retain the cost savings resulting from the consolidation. Using compute auto scaling or stopping your instance when no workload is running are some of the few ways Autonomous Database offers cost savings for our customers. However, when you have hundreds of databases requiring a fraction of an ECPU or highly oversubscribed in your on-premises systems, these options may not be sufficient. Today, I'm excited to announce the general availability of the new "Elastic Pools" feature that addresses such consolidation use cases in Autonomous Database. For the remainder of this blog, we are going to explore this new feature in the following order:

  • What is an elastic pool?
  • Key Benefits
  • Use Cases

What is an elastic pool?

An elastic pool is a logical entity where you can consolidate your Autonomous Database instances in terms of their compute allocation. You can think of it as a “family plan” for your Autonomous databases. Instead of paying individually for each one of them, they are grouped into a logical pool in which you are charged for the compute usage of the entire pool. An elastic resource pool essentially is a collection of Autonomous Database instances, potentially hundreds or even thousands of them.

Depending on the number of databases you want to fit in a pool and their compute allocation needs, you can pick one of the predefined pool sizes when you create an elastic pool. See our documentation for available pool sizes.

An elastic pool allows you to provision up to 4 times the ECPU count you have as your pool size. For example, if you have a pool with a pool size of 128 ECPUs, you can provision up to 512 ECPUs in this pool.

The pool size you set for your elastic pool is not a hard limit in terms of combined ECPU utilization of the pool members. For example, if you have 100 databases with 5 ECPUs each in your pool with a pool size of 128 ECPUs, the aggregated ECPU utilization of all pool members could add up to 500 ECPUs depending on the workload each one is running. You are only billed for the size of the elastic pool. If the aggregated ECPU utilization of all databases in the pool exceeds the pool size, you are billed for auto scaling. See our documentation for more details on billing.

Key benefits

Primary advantages of elastic pools include but not limited to:

  • Compute cost savings up to 87% versus paying for each individual instance.

    • The individual ECPU allocation of an ADB instance in an elastic pool can be as low as 1 ECPU compared to 2 ECPUs for the cases that don’t include an elastic pool.
    • The low entry point (i.e., 1 ECPU) combined with the pool capacity of 4 times the pool size provides significant cost savings.
       
  • An elastic pool is a logical grouping of Autonomous Databases. In other words, the databases that belong to a pool do not have to reside on the same physical infrastructure, unlike how database consolidation is done on on-premises.
  • The pool members in an elastic pool are not billed individually. You can allocate additional ECPUs per instance for pool members without worrying about the cost associated with the ECPU usage for the individual members. Given the IO capacity and memory allocation of an Autonomous Database is directly correlated with its ECPU allocation, selecting a greater number of ECPUs for your instance allows you to run with greater IO capacity and more memory without having to pay for the additional resources of individual pool members.

Use Cases

Elastic pools play an integral role in addressing following use cases:

  • Migrating from on-premises (or other platforms) with oversubscribed database systems
    • For example, assume I have an on-premises data center in which I oversubscribed 200 databases in a 64-core server. How can I migrate these databases to Autonomous Database without having to sacrifice my cost savings resulting from the oversubscription?

      The answer is elastic pools. I can create an elastic pool with a pool size of 128 ECPUs, in which I provision databases whose ECPU individual ECPU allocation can add up to 512 ECPUs.
       
  • Migrating large number of very small databases
    • An example could be customers who use microservices architecture and are planning to migrate all their databases to Autonomous Database.
       
  • SaaS providers who deploy hundreds or thousands of databases to store their customer data.

In conclusion, database consolidation has been a prevalent strategy among enterprises to reduce operational and infrastructure costs. While various approaches exist for implementing database consolidation on on-premises or other platforms, there hasn't been a native solution up until now to consolidate those databases under the Autonomous Database umbrella and achieve similar benefits in terms of cost savings. Autonomous Database now fills that gap thanks to our new offering, "Elastic Pools." As we have seen in this blog post, elastic pools are an invaluable tool for organizations who are in pursuit of enhancing their cost-effectiveness as they move hundreds or thousands of databases to Autonomous Database in Oracle Cloud. If you'd like to learn more about elastic pools, please check out our documentation.

Can Tuzla

Principal Product Manager

Can is a Principal Product Manager for Oracle Autonomous Database (ADB-S) and has been with the company since 2014. Prior to joining the ADB-S team, he worked on the Oracle Multitenant and Oracle Query Optimizer teams. Can holds a MS (Computer Science) from Case Western Reserve University and a BS (Computer Engineering) from Bilkent University.


Previous Post

Autonomous Tuesday at CloudWorld

Keith Laker | 5 min read

Next Post


Autonomous Wednesday at CloudWorld

Keith Laker | 6 min read
Everything you need to know about data warehousing with the world's leading cloud solution provider