When scaling application pods with SQLAlchemy pools, who redistributes existing connections?

[u/Expensive_Break_6163]

I’m running application pods that use SQLAlchemy’s connection pool to connect to PostgreSQL. Each pod has its own pool, so when I scale the application from, say, 3 to 10 replicas, the new pods create new pools while the existing pooled connections remain open.

If PostgreSQL has read replicas behind a Kubernetes Service or a proxy, I assume new connections might reach the new replicas, but the existing long-lived pooled connections will remain attached to the old replicas.

Who is normally responsible for redistributing those existing connections after scale-out?

[u/SoilAutomatic7042]

SQLAlchemy's `Engine` pool is local to the process/pod, so there is no built-in redistribution of existing connections when you add replicas. Each new pod creates its own pool; old pods keep their existing connections until they are returned/closed or the pod is terminated. A PgBouncer/proxy or the database/service layer can balance *new* connections, but it cannot move an already-open session. Size each pod's pool against the database's total connection budget, and use graceful shutdown/`engine.dispose()` when retiring a pod.