Managing Amazon Aurora PostgreSQL - Amazon Aurora

Managing Amazon Aurora PostgreSQL

The following sections discuss managing performance and scaling for an Amazon Aurora PostgreSQL DB cluster. It also includes other maintenance tasks.

Scaling Aurora PostgreSQL DB instances

You can scale Aurora PostgreSQL DB instances in two ways, instance scaling and read scaling. For more information about read scaling, see Read scaling.

You can scale your Aurora PostgreSQL DB cluster by modifying the DB instance class for each DB instance in the DB cluster. Aurora PostgreSQL supports several DB instance classes optimized for Aurora. Don't use db.t2 or db.t3 instance classes for larger Aurora clusters of size greater than 40 terabytes (TB). For detailed specifications of the DB instance classes supported by Aurora PostgreSQL, see Supported DB engines for DB instance classes.

Maximum connections to an Aurora PostgreSQL DB instance

The maximum number of connections allowed to an Aurora PostgreSQL DB instance is determined by the max_connections parameter in the instance-level parameter group for the DB instance. By default, this value is set to the following equation:

LEAST({DBInstanceClassMemory/9531392},5000)

Setting the max_connections parameter to this equation makes sure that the number of allowed connection scales well with the size of the instance. For example, suppose your DB instance class is db.r5.large, which has 16 gibibytes (GiB) of memory. Then the maximum connections allowed is around 1802, as shown in the following equation:

LEAST((16*1073741824)/9531392,5000) = 1802
Note

The DBInstanceClassMemory value represents the memory capacity, in bytes, available for the DB instance. It's a number that Aurora computes internally and isn't directly available for you to query. Aurora reserves some memory in each DB instance for the Aurora management components. This adjustment to the available memory produces a lower max_connections value than if the formula used the full memory for the associated DB instance class. You can tune the maximum number of connections to support your workload.

The following table lists the resulting default value of max_connections for each DB instance class available to Aurora PostgreSQL. You can increase the maximum number of connections to your Aurora PostgreSQL DB instance by scaling the instance up to a DB instance class with more memory, or by setting a larger value for the max_connections parameter, up to 262,143.

Instance class max_connections default value
db.r6g.16xlarge 5000
db.r6g.12xlarge 5000
db.r6g.8xlarge 5000
db.r6g.4xlarge 5000
db.r6g.2xlarge 5000
db.r6g.xlarge 3479
db.r6g.large 1722
db.r5.24xlarge 5000
db.r5.16xlarge 5000
db.r5.12xlarge 5000
db.r5.8xlarge 5000
db.r5.4xlarge 5000
db.r5.2xlarge 5000
db.r5.xlarge 3300
db.r5.large 1600
db.r4.16xlarge 5000
db.r4.8xlarge 5000
db.r4.4xlarge 5000
db.r4.2xlarge 5000
db.r4.xlarge 3200
db.r4.large 1600
db.t3.large 844
db.t3.medium 420

For the list of DB instance classes supported by Aurora PostgreSQL, see Supported DB engines for DB instance classes. For the amount of memory for each DB instance class, see Hardware specifications for DB instance classes for Aurora.

Temporary storage limits for Aurora PostgreSQL

Aurora PostgreSQL stores tables and indexes in the Aurora storage subsystem. Aurora PostgreSQL uses separate temporary storage for non-persistent temporary files. This includes files that are used for such purposes as sorting large datasets during query processing or for index build operations. For more about storage, see Amazon Aurora storage and reliability.

The following table shows the maximum amount of temporary storage available for each Aurora PostgreSQL DB instance class.

DB instance class Maximum temporary storage available (GiB)
db.r6g.16xlarge 1008
db.r6g.12xlarge 756
db.r6g.8xlarge 504
db.r6g.4xlarge 252
db.r6g.2xlarge 126
db.r6g.xlarge 63
db.r6g.large 32
db.r5.24xlarge 1500
db.r5.16xlarge 1008
db.r5.12xlarge 748
db.r5.8xlarge 504
db.r5.4xlarge 249
db.r5.2xlarge 124
db.r5.xlarge 62
db.r5.large 31
db.r4.16xlarge 960
db.r4.8xlarge 480
db.r4.4xlarge 240
db.r4.2xlarge 120
db.r4.xlarge 60
db.r4.large 30
db.t3.large 16
db.t3.medium 7.5

You can monitor the temporary storage available for a DB instance with the FreeLocalStorage CloudWatch metric, described in Amazon Aurora metrics.

For some workloads, you can reduce the amount of temporary storage by allocating more memory to the processes that are performing the operation. To increase the memory available to an operation, increasing the values of the work_mem or maintenance_work_mem PostgreSQL parameters.