SQLAlchemy connection pooling across Uvicorn workers

WHAT THIS TESTS Whether you can reason about connection limits across processes and avoid the classic production outage where the database refuses new connections. It probes understanding that pooling lives inside each engine, and engines live inside each worker process.

A GOOD ANSWER COVERS When you run Uvicorn with N workers, each is an independent OS process with its own SQLAlchemy engine and therefore its own pool. pool_size is the number of persistent connections the pool keeps open and reuses. max_overflow is how many additional connections it may open temporarily when demand exceeds pool_size; these extras are closed once returned and idle. The peak connections the database can see is N times (pool_size plus max_overflow). You must keep that product comfortably below the database server's max_connections, leaving headroom for migrations, admin tools, and other services. pool_timeout governs how long a coroutine waits for a free connection before raising.

COMMON WRONG ANSWERS Believing all workers share one pool. Setting pool_size very high to be safe, which multiplies across workers and exhausts Postgres max_connections. Forgetting that an async pool connection is held for the duration of a request, so slow queries starve the pool.

LIKELY FOLLOW-UPS How does a server-side pooler like PgBouncer change this math? What is pool_pre_ping and pool_recycle for? How do you detect pool exhaustion in metrics?

ONE CONCRETE EXAMPLE With 4 workers, pool_size 5, max_overflow 10, the database may see 4 times 15, that is 60 connections at peak. If Postgres max_connections is 100 and another service already uses 60, you exhaust connections and see QueuePool timeouts. Lowering pool_size to 5 with overflow 5 caps you at 40 and restores headroom.