
I tried to verify that the maximum capacity of Aurora Serverless (PostgreSQL) has become 384 ACU
This page has been translated by machine translation. View original
Introduction
For Aurora serverless compatible with Aurora PostgreSQL, the maximum capacity has been increased from the previous 256 ACU to 384 ACU (a 50% increase). The announcement lists supported versions as 18.4 / 17.10 / 16.14 / 15.18 / 14.23, and clusters on Platform Version 4 are eligible.
In this article, I created a PostgreSQL 18.6 cluster in the Tokyo region with a maximum of 8 ACU, changed it to a minimum of 1 / maximum of 384 ACU, and verified the cluster information. I also connected via the Data API to check the engine and architecture.
Memory Available with 384 ACU
1 ACU corresponds to approximately 2 GiB of memory. Arranging the amount of memory for each maximum capacity alongside instance classes with the same amount of memory looks like this:
| Maximum Capacity | Memory (1 ACU ≒ 2 GiB) | Instance class with the same memory |
|---|---|---|
| 256 ACU (previous maximum) | Approx. 512 GiB | db.r7g.16xlarge, db.r8g.16xlarge (512 GiB) |
| 384 ACU | Approx. 768 GiB | db.r8g.24xlarge (768 GiB) |
For Aurora PostgreSQL 18.6 in the Tokyo region, the available db.r6g and db.r7g sizes go up to 16xlarge (512 GiB), and 24xlarge is a size available starting from db.r8g.
Creating the Cluster
Whether 384 ACU can be configured depends on the engine version. The maximum capacity per version can be verified with describe-db-engine-versions under ServerlessV2FeaturesSupport.MaxCapacity. The results for PostgreSQL versions 17.x and 18.x in the Tokyo region were as follows:
$ aws rds describe-db-engine-versions --engine aurora-postgresql --region ap-northeast-1 --query 'DBEngineVersions[].[EngineVersion,ServerlessV2FeaturesSupport.MaxCapacity]' --output text
17.4 256.0
17.5 256.0
17.6 256.0
17.7 256.0
17.9 256.0
17.10 384.0
17.11 384.0
18.3 256.0
18.4 384.0
18.6 384.0
The announcement's list of supported versions goes up to 18.4, but 18.6 also returned 384.0. For versions 14.x through 16.x omitted from the output, versions 14.23 / 15.18 / 16.14 and later returned 384.0, while earlier versions returned 256.0 or below.
The cluster is created with a maximum of 8 ACU, with the Data API and managed secret enabled. An instance is added and we wait until it becomes available.
aws rds create-db-cluster \
--db-cluster-identifier <cluster name> \
--engine aurora-postgresql \
--engine-version 18.6 \
--master-username postgres \
--manage-master-user-password \
--db-subnet-group-name <DB subnet group name> \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=8 \
--enable-http-endpoint \
--no-deletion-protection \
--region ap-northeast-1
aws rds create-db-instance \
--db-instance-identifier <instance name> \
--db-cluster-identifier <cluster name> \
--db-instance-class db.serverless \
--engine aurora-postgresql \
--region ap-northeast-1
aws rds wait db-instance-available \
--db-instance-identifier <instance name> \
--region ap-northeast-1
Changing Maximum Capacity to 384 ACU
The maximum capacity is changed using modify-db-cluster. This time, a minimum of 1 / maximum of 384 was specified.
$ aws rds modify-db-cluster --db-cluster-identifier <cluster name> --serverless-v2-scaling-configuration MinCapacity=1,MaxCapacity=384 --apply-immediately --region ap-northeast-1 --query 'DBCluster.[Status,ServerlessV2ScalingConfiguration]' --output json
[
"available",
{
"MinCapacity": 1.0,
"MaxCapacity": 384.0
}
]
The Status in the response was available, but afterward both the cluster and instance temporarily entered a modifying state. I waited for them to return to available using wait db-instance-available, then verified with describe-db-clusters.
$ aws rds describe-db-clusters --db-cluster-identifier <cluster name> --region ap-northeast-1 --query 'DBClusters[0].{Status:Status,Scaling:ServerlessV2ScalingConfiguration,PV:ServerlessV2PlatformVersion}' --output json
{
"Status": "available",
"Scaling": {
"MinCapacity": 1.0,
"MaxCapacity": 384.0
},
"PV": "4"
}
For clusters where the PV (ServerlessV2PlatformVersion) in the output is older than 4, upgrade to Platform Version 4 via pending maintenance actions. For clusters running versions that returned 256.0 in the previous section, update the engine version along with the maximum capacity. The announcement states that clusters on Platform Version 4 can change the maximum capacity without downtime.
The ParameterApplyStatus of the instance's default.aurora-postgresql18 was in-sync during the change, but after returning to available it became pending-reboot. Some parameters such as max_connections will retain values based on the previous maximum capacity until the instance is rebooted.
Verifying the Engine via Data API
I ran select version() and select aurora_version() using the Data API's execute-statement. The secret ARN can be obtained from MasterUserSecret.SecretArn in describe-db-clusters.
$ aws rds-data execute-statement --resource-arn <cluster ARN> --secret-arn <secret ARN> --database postgres --sql 'select version()' --region ap-northeast-1 --output json
{
"records": [
[
{
"stringValue": "PostgreSQL 18.6 on aarch64-linux, compiled by gcc-10.5.0, 64-bit"
}
]
],
"numberOfRecordsUpdated": 0
}
$ aws rds-data execute-statement --resource-arn <cluster ARN> --secret-arn <secret ARN> --database postgres --sql 'select aurora_version()' --region ap-northeast-1 --output json
{
"records": [
[
{
"stringValue": "18.6.1"
}
]
],
"numberOfRecordsUpdated": 0
}
The Aurora version was 18.6.1, and PostgreSQL 18.6 was built for aarch64 (64-bit Arm).
Summary
Aurora serverless for Aurora PostgreSQL can now be configured with a maximum capacity of up to 384 ACU, making the equivalent maximum performance of a provisioned db.r8g.24xlarge available.
With the increased ACU limit, workloads that previously found 256 ACU insufficient for DB performance now have a greater chance of considering Aurora serverless as a viable option.
This time, only the Aurora PostgreSQL-compatible DB engine supported 384 ACU, but I look forward to Aurora MySQL-compatible support as well.
