---
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.factualminds.com/blog/database-deadlocks-connection-pools-prepared-statements-rds/
datePublished: 2026-06-12T00:00:00.000Z
dateModified: 2026-06-12T00: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 **~5,000** ceiling on `db.r6g.xlarge`, before autovacuum and admin connections consume headroom.

> **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](/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—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** — dedicated connection, not app pool.

## What to do this week

1. Graph `DatabaseConnections` vs `max_connections` on writer.
2. Deploy RDS Proxy if >20 clients connect independently.
3. Set `idle_in_transaction_session_timeout` (e.g. 60s) in parameter group.
4. Enable Performance Insights wait events `Lock:deadlock` and `Client:ClientRead`.

## What this guide doesn't cover

Read replica lag and failover—see canonical [RDS vs Aurora](/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/plan once, execute many. ORMs often disable or duplicate prepared statements per pool connection; verify PgBouncer/RDS Proxy transaction vs session pooling mode compatibility.

---

*Source: https://www.factualminds.com/blog/database-deadlocks-connection-pools-prepared-statements-rds/*