Each Postgres connection consumes memory. App servers opening thousands of connections exhaust resources—poolers multiplex clients onto fewer server connections.
Why pool
Postgres forks a backend per connection. Web apps with many workers need PgBouncer, Odyssey, or managed poolers—not raw unbounded connections.
PgBouncer modes (concept)
- Transaction pooling — connection returned after each transaction—best for stateless web requests
- Session pooling — holds connection for client session—needed for prepared statements tied to session
Django and Python notes
Django CONN_MAX_AGE persists connections per worker—still use external pooler at scale. Python apps use psycopg connection pools (psycopg_pool) with sane max size.
Practice: Use local or staging environments only for backup/restore and pooling experiments.
Important interview questions and answers
- Q: Too many connections symptom?
A: Errors like too many clients already—fix with pooler or raise max_connections carefully. - Q: Prepared statements + pooling?
A: Transaction pooling breaks session-scoped prepared statements—configure ORM/driver accordingly.
Self-check
- Name one pooling tool for Postgres.
- Why not open one connection per HTTP request without pooling?
Tip: Pair Django CONN_MAX_AGE with PgBouncer at scale—not one or the other blindly.
Interview prep
- Why pool?
Limits server backends—each connection uses memory.
- PgBouncer?
Popular connection pooler multiplexing clients.