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:
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.
Primary advantages of elastic pools include but not limited to:
Compute cost savings up to 87% versus paying for each individual instance.
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.
Elastic pools play an integral role in addressing following use cases:
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 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.