Understanding Amazon RDS Connection Limits
Calculate the maximum number of connections for Amazon RDS across different instance types
Have you ever run into database connection limits, or felt unsure about which RDS instance type to choose when planning your system architecture?
This article walks you through how Amazon RDS calculates its maximum connections and provides a comparison across different instance types to help you make better decisions.
In a new company project, I noticed that RDS was quite unstable and frequently encountered various connection errors.
After investigation, I discovered that the RDS instance hosted multiple databases and was shared across several projects.
At first, I suspected that AWS Lambda functions were creating too many connections at runtime, causing RDS to run out of available resources.
This led me to calculate the maximum number of connections for RDS across different instance types to verify whether my assumption was correct, and to use it as a reference for future upgrades.
Formula
The formula for calculating the maximum number of database connections (max_connections) is documented here: Amazon RDS Database Connection Limits
max_connections = LEAST({DBInstanceClassMemory/9531392}, 5000)
For example, if RDS is running PostgreSQL on a db.t4g.medium instance:
According to the Amazon RDS instance types
documentation, the memory is 4 GiB.
(1 GiB = 1,073,741,824 bytes, so 4 GiB = 4,294,967,296 bytes)
Maximum connections: 4294967296 / 9531392 = 450
If multiple databases exist within the same RDS instance, they must share these connections.
Other Instance Class
| Instance Type | max_connections |
vCPU | Memory (GiB) |
|---|---|---|---|
| db.t4g.micro | 112 | 2 | 1 |
| db.t4g.small | 225 | 2 | 2 |
| db.t4g.medium | 450 | 2 | 4 |
| db.t4g.large | 910 | 2 | 8 |
| db.t4g.xlarge | 1802 | 4 | 16 |
| db.t4g.2xlarge | 3604 | 8 | 32 |
Postscript
After running the calculations, I realized that the maximum connections were far from being exhausted.
Digging deeper into the code, I discovered that the real issue came from one particular service that was performing heavy database operations.
This even included a DB trigger that was never documented in the project specifications.
The next step is to carefully analyze what that undocumented service is actually doing.
Depending on the findings, the plan might be to decommission the service and then adjust RDS accordingly.
This could mean upgrading the instance type or splitting workloads into multiple instances.
