There are several terms to use when you work with elastic pools:

• Pool Leader: The Autonomous Database instance that creates an elastic pool.
• Pool Member: An Autonomous Database instance that is added to an elastic pool.
• Pool Size: A value you set when creating an elastic pool. The pool size must be one of the available elastic pool shapes.
• Pool Shape: When you create an elastic pool, you select a pool shape from among the valid pool sizes. The shape must have one of 128, 256, 512, 1024, 2048, or 4096 ECPUs.
• Pool Capacity: The maximum number of ECPUs that an elastic pool can use. It is four times (x4) the pool size.

Elastic pools provide the following benefits. They:

• Enable operating with a fixed budget for a group of databases while delivering performance elasticity for each individual database.
• Allow for easy migration from on-premise Oracle environments that include oversubscription to provide a cost-effective way to move to an Autonomous Database.
• Support SaaS vendors with a large number of individual customer databases.
• Provide resources for using a microservices architecture, where the ability to supply a large number of databases is required.
• The pool members in an elastic pool are not billed individually (the pool leader is billed based on the pool shape). You can allocate additional ECPUs per instance for pool members without worrying about the cost associated with the ECPU usage for the individual members.
• Autonomous Database memory allocation is directly correlated with the ECPU count, so selecting a greater number of ECPUs for instance allows you to run with more memory without paying for the additional resources. This means using a larger number of ECPUs per instance will enable you to use more memory per instance, where the cost is based on the pool shape and not on an individual instance's ECPU count.

The following are the requirements for an Autonomous Database instance to create an elastic pool and become a pool leader:

• The instance must use the ECPU compute model without Autonomous Data Guard.
• The instance must be an Autonomous Database with Autonomous Transaction Processing workload type. This only applies to the pool leader. An elastic pool can hold a mix of databases with Autonomous Transaction Processing and Autonomous Data Warehouse workloads.
• Auto scaling must be disabled.
• The instance must not be a member of an existing elastic pool.
• The maximum allowed individual ECPU count for an Autonomous Database instance that creates an elastic pool is 4 times the pool size specified when you create the pool.
• The instance that creates an elastic pool is subject to tenancy limits. To create an elastic pool, you must have a sufficient number of ECPUs available, below the tenancy limit, to accommodate the size of the elastic pool.

The following are the requirements for an Autonomous Database instance to join an elastic pool:

• The instance must use the ECPU compute model without Autonomous Data Guard.
• An elastic pool can contain Autonomous Database instances with Autonomous Transaction Processing and Autonomous Data Warehouse workload types.
• Auto scaling must be disabled.
• The instance must not be a member of an existing elastic pool.
• The available pool capacity is the maximum allowed individual ECPU count for an Autonomous Database instance. When an instance's ECPU count is greater than the available pool capacity, it is not allowed to join that elastic pool.

An elastic pool has a pool capacity of 4 times the pool size. For example, a pool with pool size of 128 ECPUs can hold up to 512 ECPUs for its leader and the members.

The following are examples of Autonomous Database instances that could be in an elastic pool with a pool size of 128 and a pool capacity of 512 ECPUs:

• Each of these are valid for pool members in an elastic pool with a pool size of 128 ECPUs:

  • 1 instance with 512 ECPUs, for a total of 512 ECPUs

  • 128 instances with 4 ECPUs, for a total of 512 ECPUs

  • 256 instances with 2 ECPUs, for a total of 512 ECPUs

• Similarly, each of the following are valid for pool members in an elastic pool with a pool size of 128 ECPUs:

  • 1 instance with 128 ECPUs, 2 instances with 64 ECPUs, 32 instances with 4 ECPUs, and 64 instances with 2 ECPUs, for a total of 512 ECPUs

  • 256 instances with 1 ECPU, 64 instances with 2 ECPUs, for a total of 384 ECPUs, which is less than the pool capacity of 512 ECPUs.

The Autonomous Database instance that creates an elastic pool is the pool leader.

The Autonomous Database instance that are added to an existing pool are pool members.

• Starting and stopping Autonomous Database instances that are members of an elastic pool does not depend on the state of the leader. That is, you can independently stop and start each instance that is part of an elastic pool, including the leader and members of the elastic pool that are not the leader.

• Provisioning a pool leader or a member is subject to service limits enforced at the tenancy or compartment levels.

• In an elastic pool, the pool leader's licensing selections determine the license requirements for the entire pool. The license selections for pool members do not apply while an instance is a member of a pool. They come into effect only if a pool member leaves the elastic pool.