Connection Pooling — When App Scaling Floods the DB
Scale the app to 50 instances and each opens its own database connections — the DB blows past its connection limit and rejects everyone. Add a pool and a few hundred shared connections serve every instance.
This is the trap behind "we scaled the app and the database fell over." Add instances and watch connections pile onto the DB — then drop a pooler in between and watch the count flatten.
8 instances
each opens 15 connections · DB accepts 300 max
App wants
120 conns
DB actually sees
120 conns
DB limit
300
🗄️ Database connections120 / 300
8 instances
→
🗄️
Database
120 connections so far. Keep adding instances and you'll cross 300 and the DB will start refusing connections.
What just happened
▹Every app instance opens its own pool of database connections. Scale the app to 50 instances and the connection count explodes — 50 × 15 = 750 — far past what the database will accept.
▹A database has a hard connection limit. Blow past it and it doesn't slow down gracefully; it rejects new clients outright. Scaling the app can take the database down.
▹A connection pooler (PgBouncer, RDS Proxy, an app-side pool) keeps a small fixed set of connections to the DB and lends them out to all instances. The DB sees a safe, constant number no matter how far the app scales — instances just briefly wait their turn under peak.