AWS RDS Support
Fix RDS "too many connections" errors.
MySQL reports ERROR 1040 Too many connections and PostgreSQL reports remaining connection slots are reserved or too many clients already. Raising max_connections is rarely the right first move, because each connection uses memory. We find who opens the connections and why, then fix the pattern.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Applications get connection refused or too many connections errors
- Lambda or autoscaling groups open new connections per invocation or per instance
- Connection counts climb during deploys and never come down
- Admin logins fail during an incident because the limit is reached
- You raised max_connections and the instance now runs out of memory
What you get
- A connection analysis showing sources and leak patterns
- Application pool and timeout configuration changes
- RDS Proxy or pooler design where appropriate
- Parameter group changes and connection alarms
How we do it
A clear, safe process you can follow along with.
1. Measure the connection pattern
We graph DatabaseConnections against the engine's max_connections, which defaults to a formula based on instance memory. We look at whether growth tracks traffic, deploys or a steady leak.
2. List who is connected
On MySQL we query information_schema.processlist and on PostgreSQL pg_stat_activity, grouped by user, host and state. Many idle or idle in transaction sessions point to leaks or poor pooling.
3. Fix application pooling
We make sure each app instance uses a bounded pool, closes connections after use, and that pool size multiplied by instance count fits the database limit, including during autoscaling and rolling deploys.
4. Fix serverless patterns
Lambda can create one connection per concurrent execution. We reuse connections across invocations, cap function concurrency and put RDS Proxy in front of the database.
5. Clean up stuck sessions
We set sensible timeouts such as wait_timeout on MySQL or idle_in_transaction_session_timeout on PostgreSQL, and fix code that leaves transactions open.
6. Tune the limit only with evidence
If the real concurrent workload needs more, we raise max_connections in a custom parameter group, checking memory per connection and that the instance class can support it. Some changes need a reboot to apply, depending on the parameter.
7. Alarm before it hurts
We add CloudWatch alarms on DatabaseConnections at a percentage of the limit and on pool wait times in the application.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Setting max_connections very high
Memory per session and context switching can make the instance slower or crash it. A pool is a better answer.
Ignoring idle in transaction sessions
They hold locks and snapshots, causing bloat and blocking on PostgreSQL.
Sizing pools per host without multiplying
Fifty instances with pools of fifty need 2,500 connections. We do the arithmetic.
Frequently Asked Questions
What is the default max_connections on RDS?
It is computed from the instance class memory using a formula in the default parameter group, and it differs by engine. Check the parameter group for your instance.
Will raising max_connections fix the error?
It removes the symptom for a while but increases memory use. Pooling and fixing leaks address the cause.
Does RDS Proxy fix too many connections?
Often yes for bursty or serverless clients, because it multiplexes many client connections onto fewer database connections, though pinned sessions reduce the benefit.
Want Help With Fix RDS "too many connections" errors?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required