How RDS sets the default max_connections
The default parameter group of each engine sets the connection limit with a formula over DBInstanceClassMemory, the instance class's memory in bytes - so a class with twice the memory gets twice the connections, up to a cap:
| Engine | Parameter | Default |
|---|---|---|
| RDS for MySQL | max_connections | {DBInstanceClassMemory/12582880} - about one per 12 MiB |
| RDS for MariaDB 10.5 and higher | max_connections | LEAST({DBInstanceClassMemory/25165760},12000) - about one per 25 MiB, at most 12,000 (10.4 used MySQL's formula) |
| RDS for PostgreSQL, Aurora PostgreSQL | max_connections | LEAST({DBInstanceClassMemory/9531392},5000) |
| RDS for Oracle | processes | LEAST({DBInstanceClassMemory/9868951}, 20000) |
| RDS for SQL Server | user connections | 0 - unlimited, which is SQL Server's maximum of 32,767; set in the server properties |
| RDS for Db2 | - | 64,000, and it cannot be changed |
| Aurora MySQL | max_connections | AWS's table per instance class: 1,000 on a db.r6g.large, 1,000 more each time the memory doubles; 45 to 135 on the T classes; settable up to 16,000 |
The division truncates: the result is always a whole number.
Why the real value is lower than the formula
DBInstanceClassMemory is not the class's full memory: RDS first subtracts what the operating system and its own management processes reserve, and AWS does not publish how much - it depends on the class, the engine and whether the instance is part of an Aurora cluster. That is why the calculator shows the formulas' results as "≤". AWS's own example: a MySQL instance with 8 GiB, like a db.m7g.large, would get about 683 from the full memory but gets about 630; on a db.t3.micro the reserved share is so large that MySQL gets about 60. The exact value is one query away:
SHOW GLOBAL VARIABLES LIKE 'max_connections'; -- MySQL, MariaDB, Aurora MySQL
SHOW max_connections; -- PostgreSQL, Aurora PostgreSQL Aurora MySQL's table lists the values Aurora really uses, rounded to steady steps. Aurora Serverless v2 keeps max_connections constant, at the value for its maximum capacity, so that scaling down never drops connections; changing the maximum capacity needs a reboot to change it. On Aurora PostgreSQL with a minimum of 0 or 0.5 ACUs it is at most 2,000.
The connection budget: Lambda, pods and RDS Proxy
Every client holds its connections whether it uses them or not, and max_connections counts them all:
- Lambda runs every concurrent request in an execution environment of its own, so a function that keeps one connection per environment holds as many as its concurrency - up to 1,000 per Region by default, shared by all functions. Reserved concurrency caps a function (
put-function-concurrency); AWS keeps at least 100 unreserved for the other functions. - Pods, ECS tasks and servers each open their own pool, so the database sees the replica count times the pool size - and more during a rolling deployment, when old and new replicas run together.
- Aurora replicas and RDS read replicas each have their own
max_connections; readers take load off the writer's budget only for the clients that connect to them.
RDS Proxy holds a pool of database connections and lends one to a client connection for a transaction, so many clients share few connections. The pool is at most MaxConnectionsPercent of max_connections - 100 by default, 10 on SQL Server - and connections that do not go through the proxy need what is left. The proxy also keeps a few connections for its own monitoring and failover, which is why AWS recommends at least 20% (30% on a db.t3.small) and 30% headroom above the busiest use you have seen. A session that changes connection state can be pinned to its database connection until it ends; with enough pinning, clients wait for a free connection up to ConnectionBorrowTimeout (120 seconds by default) and then fail. RDS Proxy is not available for Oracle and Db2.
Frequently asked questions
Can I raise max_connections?
Yes, in a custom DB parameter group (a DB cluster parameter group on Aurora PostgreSQL) - up to 100,000 on MySQL and MariaDB, 262,143 on PostgreSQL, 16,000 on Aurora MySQL. Every connection uses memory, though: set it too high and the instance can run out of memory, and RDS puts it in the incompatible-parameters state. A larger instance class or RDS Proxy is usually the better fix.
Why does my db.t3.micro allow so few connections?
With 1 GiB of memory, the share RDS reserves for the operating system is a large part of the instance, so the formula runs on much less than 1 GiB: MySQL gets about 60 connections instead of the 85 the full memory would give.
Where does the data come from?
The memory and vCPUs of each DB instance class and the engines it is sold with come from the AWS Price List API; Aurora MySQL's and Aurora Serverless v2's defaults from their tables in the Aurora documentation - read again on every build of this site, last on 2026-09-28. The formulas are those of the RDS and Aurora documentation, and every build checks they are still there.
Is what I enter sent anywhere?
No. The calculation runs in your browser. The page only counts that the calculator was used, with the engine and whether RDS Proxy is on, never the numbers.
References
Maximum number of database connections (Amazon RDS User Guide)
Specifying DB parameters: DBInstanceClassMemory (Amazon RDS User Guide)
Maximum connections to an Aurora MySQL DB instance (Amazon Aurora User Guide)
Maximum connections to an Aurora PostgreSQL DB instance (Amazon Aurora User Guide)
Maximum connections for Aurora Serverless v2 (Amazon Aurora User Guide)
RDS Proxy connection considerations (Amazon RDS User Guide)
Understanding Lambda function scaling (AWS Lambda Developer Guide)
AWS Price List API