--- title: Database Deadlocks, Connection Pool Exhaustion, and Prepared Statements on RDS description: Too many "too many connections" pages are fixed by raising max_connections, which trades one outage for OOM on the writer. This guide traces deadlocks, pool sizing, RDS Proxy, and prepared statement caching on Aurora. url: https://www.joinhorizon.co/blog/database-deadlocks-connection-pools-prepared-statements-rds/ datePublished: 2026-06-12T00:00:00.000Z dateModified: 2026-10-28T00:00:00.000Z author: palaniappan-p category: Cloud Architecture tags: engineering-guide, database, rds, aurora, performance, aws --- # Database Deadlocks, Connection Pool Exhaustion, and Prepared Statements on RDS > Too many "too many connections" pages are fixed by raising max_connections, which trades one outage for OOM on the writer. This guide traces deadlocks, pool sizing, RDS Proxy, and prepared statement caching on Aurora. **June 2026**: Aurora PostgreSQL `max_connections` scales with instance class, not with your microservice count. A fleet of 80 ECS tasks × pool size 20 = **1,600** client slots fighting a **~3,600** default ceiling on `db.r6g.xlarge` (`LEAST(DBInstanceClassMemory/9531392, 5000)`), before autovacuum and admin connections consume headroom. ## Symptom → mechanism → AWS control | Production symptom | Mechanism | AWS control | | ------------------------ | ------------------------------------- | -------------------------------------------------- | | Random 40x errors | Connection pool exhausted | RDS Proxy, right-size max_connections | | Cyclic deadlock restarts | Lock ordering inversion | Consistent row-lock order, shorter transactions | | Plan cache bloat | Unbounded prepared statement variants | Parameterized queries; watch RDS Proxy pinning | **Opinionated take:** Put RDS Proxy in front of every multi-instance app tier and fix deadlocks with lock ordering before you scale connection counts. > **Benchmark pattern (hypothetical workload):** RDS PostgreSQL with 200-connection pool via RDS Proxy, deadlock rate 3.2/hour on concurrent UPDATE without ordering; prepared statements reduce parse overhead 18%, pool exhaustion alerts at 95% max_connections. > **Field note:** Logistics SaaS (~$18k/mo Aurora): p99 API **5.2 s** during deploy; `pg_stat_activity` showed **4,800** connections, mostly `idle in transaction` from a leaked ORM session. RDS Proxy + pool cap **15**/task dropped connections to **620**; p99 **220 ms**. Use [RDS max connection calculator](https://www.joinhorizon.co/tools/aws-rds-max-connection-calculator/). ## Deadlock detection PostgreSQL logs `deadlock detected` with cycle details. Fix **lock order** (always lock parent row before child), shorten transactions, avoid user prompts inside transactions. ## Connection pool exhaustion | Cause | Signal | Fix | | ------------------------- | ------------------------------------------- | -------------------------------------- | | Pool > DB max | `FATAL: too many connections` | RDS Proxy; reduce per-task pool | | Idle in transaction | `idle in transaction` in `pg_stat_activity` | Timeouts; code review | | Thundering herd deploy | Spike on rollout | Staggered deploy; Proxy borrow timeout | | Lambda per invoke connect | Connection storm | Proxy + Data API for light queries | ## Prepared statements Use for hot queries; watch **RDS Proxy** pinning, since session-level prepared statements may not multiplex identically to transaction pooling. ## AWS services map | Control | Service | | ----------------- | ----------------------------------------------------- | | Multiplexing | RDS Proxy | | Connection math | Performance Insights + `max_connections` | | Break-glass scale | Aurora Serverless v2 ACU bump (not a pool substitute) | ## When this advice breaks - **Aurora Limitless:** shard-aware pooling differs; consult shard router docs. - **Single long-running ETL:** use a dedicated connection, not app pool. ## What to do this week 1. Graph `DatabaseConnections` vs `max_connections` on writer. 2. If the app is still a monolith, run [step 2 of the scale-in-place ladder](https://www.joinhorizon.co/blog/aws-legacy-monolith-scale-in-place-before-decomposition-2026/) before adding read replicas. 3. Deploy RDS Proxy if >20 clients connect independently. 4. Set `idle_in_transaction_session_timeout` (e.g. 60s) in parameter group. 5. Watch Performance Insights wait events `Lock:transactionid` and `Client:ClientRead`, and alert on the `deadlocks` counter in `pg_stat_database` (PostgreSQL also logs `deadlock detected`). ## More in This Track Part of the **Engineering Guides** library (June 2026). - Previous: [Part 2](https://www.joinhorizon.co/blog/btree-lsm-query-planner-database-engine-internals/) - Next: [Part 4](https://www.joinhorizon.co/blog/postgresql-vacuum-index-bloat-sharding-hot-partitions-aws/) - Browse tracks: [Engineering Guides hub](https://www.joinhorizon.co/resources/engineering-guides/) ## What this guide doesn't cover Read replica lag and failover: see canonical [RDS vs Aurora](https://www.joinhorizon.co/compare/aws-rds-vs-aurora/) guides. ## FAQ ### When does RDS Proxy pay for itself? When you have many short-lived Lambdas or ECS tasks each opening pools to the same Aurora cluster. Proxy multiplexes application connections onto fewer DB connections. It does not remove the need for query tuning or fix N+1 queries. ### Do prepared statements help on RDS? Yes for repeated OLTP statements: parse and plan once, execute many times. ORMs often disable or duplicate prepared statements per pool connection; verify PgBouncer/RDS Proxy transaction vs session pooling mode compatibility. --- *Source: https://www.joinhorizon.co/blog/database-deadlocks-connection-pools-prepared-statements-rds/*