Aurora MySQL 8.4.10 Has Been Released, So I Checked Out What Changed
This page has been translated by machine translation. View original
Introduction
On November 2, 2026, the GA of Aurora MySQL 8.4.10, compatible with MySQL 8.4.10, was announced.
The changes in the previous version, 8.4.8, are summarized in the following article.
This time, centered on the max_connections value of up to 50,000 per DB instance supported in 8.4.10, I will introduce the results of setting 16001, 30000, and 50000 on Aurora Serverless v2 and checking the applied values with the Data API.
Key changes in 8.4.10
Among the new features, faster minor version upgrades (from 8.4.7 or 8.4.8 to 8.4.10, with no configuration changes or opt-in required) and GTID tags, which identify and group transactions in binary log replication, have been added.
The highlight of the improvements is the raised upper limit of max_connections (from 16,000 to 50,000), which this article verifies. In addition, there is support for the RETURNING clause in DELETE, additional CloudWatch metrics, and bug fixes related to XA transactions and asynchronous replication. See the release notes for details on each item.
Setting max_connections above 16,000
Official documentation
The maximum value of max_connections (the upper limit on concurrent connections) has been raised from 16,000 to 50,000 in 8.4.10 and later. This makes it easier to accommodate applications with many connections as-is, without placing a connection pooling layer in between. This value is set in the instance-level DB parameter group.
However, the user guide recommends using an instance class of 24xlarge or larger when setting a value above 16,000. It also recommends using RDS Proxy together in cases with frequent connection opening and closing or many long-lived connections. Note that appropriate sizing and configuration are required, not just raising the limit.
Test environment
I created an Aurora MySQL 8.4.10 cluster with Aurora Serverless v2 at a minimum of 1 ACU and a maximum of 8 ACU. There is one writer instance, and the Data API is enabled on the cluster. max_connections is set in the DB parameter group.
Commands to create the cluster, instance, and parameter group
export AWS_PROFILE=<profile> AWS_REGION=ap-northeast-1
# DB parameter group (instance level)
aws rds create-db-parameter-group \
--db-parameter-group-name devio-8410-maxconn \
--db-parameter-group-family aurora-mysql8.4 \
--description "devio 8.4.10 max_connections check"
# Cluster (Serverless v2 1-8 ACU, Data API enabled, master password managed by RDS)
aws rds create-db-cluster \
--db-cluster-identifier devio-8410 \
--engine aurora-mysql --engine-version 8.4.mysql_aurora.8.4.10 \
--master-username admin --manage-master-user-password \
--serverless-v2-scaling-configuration MinCapacity=1,MaxCapacity=8 \
--enable-http-endpoint \
--db-subnet-group-name <サブネットグループ（2AZ以上）> \
--storage-encrypted --no-deletion-protection
# Writer instance (specify the DB parameter group at creation)
aws rds create-db-instance \
--db-instance-identifier devio-8410-writer \
--db-cluster-identifier devio-8410 \
--engine aurora-mysql --db-instance-class db.serverless \
--db-parameter-group-name devio-8410-maxconn
Results of setting and applying
The command that set max_connections to 16001 is as follows. For 30000 and 50000, I ran the same command changing only ParameterValue.
aws rds modify-db-parameter-group \
--db-parameter-group-name devio-8410-maxconn \
--parameters ParameterName=max_connections,ParameterValue=16001,ApplyMethod=immediate
To check the applied value, I obtained the cluster ARN and the secret ARN, then ran SELECT @@max_connections with the Data API.
CL_ARN=$(aws rds describe-db-clusters --db-cluster-identifier devio-8410 --query 'DBClusters[0].DBClusterArn' --output text)
SEC_ARN=$(aws rds describe-db-clusters --db-cluster-identifier devio-8410 --query 'DBClusters[0].MasterUserSecret.SecretArn' --output text)
aws rds-data execute-statement --resource-arn "$CL_ARN" --secret-arn "$SEC_ARN" \
--sql "SELECT @@max_connections" --format-records-as JSON --query formattedRecords --output text
The responses, from top to bottom, are for when the parameter was not set, after setting 16001, after setting 30000, and after setting 50000. Only for the unset case, I also retrieved the version with SELECT @@version, @@max_connections.
[{"@@version":"8.4.10","@@max_connections":1000}]
[{"@@max_connections":16001}]
[{"@@max_connections":30000}]
[{"@@max_connections":50000}]
The definition of max_connections when the parameter is not set is as follows.
[
{
"Name": "max_connections",
"Value": "GREATEST({log(DBInstanceClassMemory/805306368)*45},{log(DBInstanceClassMemory/8187281408)*1000})",
"Source": "system",
"ApplyType": "dynamic",
"IsModifiable": true,
"AllowedValues": "1-50000"
}
]
Because it is a dynamic parameter with an ApplyType of dynamic, all of 16001, 30000, and 50000 were applied without rebooting the DB instance by specifying ApplyMethod=immediate.
Note that what I confirmed here is only that the setting values were accepted and applied. I have not verified behavior with more than 16,000 connections.
Support period and version selection
End of standard support dates
The three Aurora MySQL 8.4 versions listed in the release calendar are as follows.
| Aurora MySQL version | Release date | End of standard support |
|---|---|---|
| 8.4.10 | 2026-10-26 | 2028-04-30 |
| 8.4.8 | 2026-09-03 | 2028-03-31 |
| 8.4.7 | 2026-05-21 | 2027-11-30 |
8.4.10 is not labeled as LTS, and its end of standard support date is 2028-04-30. Standard support for the major version 8.4 as a whole is scheduled to last until April 2032.
Summary
Aurora MySQL 8.4.10 is a minor update version compatible with MySQL 8.4.
It includes not only the raised max_connections limit introduced here but also CVE fixes and bug fixes, and AWS recommends updating to the new minor version. If you are using Aurora MySQL 8.4, I recommend considering an update.
