Who Rebalances Existing Database Connections When Application Pods Scale?
Asked by
MellowCedar42
I'm running multiple application pods that connect to PostgreSQL through SQLAlchemy. Each pod maintains its own connection pool, so scaling from three replicas to ten creates several new pools while connections already held by the original pods remain open.
If PostgreSQL read replicas sit behind a Kubernetes Service or another proxy, new connections may be routed to newly available replicas. However, existing pooled connections are still attached to the database instances they originally reached.
When scaling out changes the desired connection distribution, what component is normally responsible for handling existing connections? Does the application pool, a connection pooler, or the proxy need to recycle or rebalance them?
Answers
Your assumption is mostly correct: an already-open pooled connection stays connected to its original PostgreSQL instance until the application closes it or the connection is dropped. The proxy cannot usually move a live database session to another replica without disrupting that session.
The usual solution is connection lifecycle management. Configure pool recycling, idle timeouts, health checks, and graceful draining so connections are replaced over time rather than expecting an immediate rebalance. If the pools only retain connections for a few minutes or tens of minutes, the distribution will often correct itself naturally after scaling.
Reply to this answer
Scaling the application pods by itself won’t rebalance connections that are already open. SQLAlchemy’s pool keeps those connections associated with the database instance they reached, and a Service or load balancer generally only affects newly established connections.
In practice, existing connections are redistributed through normal pool lifecycle behavior: idle connections are closed, recycled, or replaced according to the pool settings. A connection pooler such as PgBouncer or PgDog can also sit between the application and PostgreSQL, managing connection lifetimes and making it easier for the database and application layers to scale independently.
Reply to this answer
Add your answer
Answers are reviewed before publication.
QuietMaple19: That does move some of the responsibility to the pooler, but it also gives you one place to manage database connections instead of having every application pod maintain its own separate set. If the pooler itself is scaled out, each pooler instance still manages its own connections, so its deployment and draining strategy matter too.