Replit Autoscale deployment: database connection pool lifetime during scale-to-zero

Answer to the Core Question

In an Autoscale deployment on Replit, the application runs inside a container that is terminated when the instance becomes idle. The connection pool you create in the application lives in that container’s memory; when the process exits, the pool is destroyed. The pool is not persisted across scale‑to‑zero and is rebuilt from scratch on the next cold start. There is no documented graceful drain of the pool – the container simply exits, severing the TCP connections. The same applies to any managed PostgreSQL integration; the key‑value store is platform‑managed and does not use a user‑configured pool.

Why the Pool Is Destroyed

• Connection pools are in‑process data structures; they cannot survive a process exit.
• Replit’s Autoscale terminates the container with a standard OS shutdown sequence, which closes open sockets without an application‑level clean‑up hook.
• On the next request, a fresh container starts, a new process is spawned, and the application code re‑initialises the pool.

Implications for Pool Configuration

1. Pool size must be tuned for steady‑state traffic. A large minimum pool will waste connections that are immediately lost when the instance scales to zero.
2. Connection churn is inevitable. Each cold start triggers new TCP/TLS handshakes and a new PostgreSQL session. Rapid scale‑up can cause a burst of simultaneous connections, potentially hitting max_connections or rate limits on the managed database.
3. Idle timeout settings on the database side are irrelevant to the pool’s lifetime. Connections are closed by the container shutdown, not by the database.

Verification Steps for Your Deployment

1. Instrument your application to log the following events:
   • Process start (e.g., console.log('app started'))
   • Signal receipt (if you handle SIGTERM)
   • Pool shutdown (e.g., pool.end() callback)
   • Pool creation (e.g., pool = new Pool())
2. On Replit, monitor the deployment’s idle timer via the console or API to see when the container stops.
3. Query the managed PostgreSQL pg_stat_activity view around the idle‑to‑active transition to observe abrupt connection drops and new session creations.
4. Measure the latency of the first request after a cold start; a noticeable delay indicates the time spent re‑establishing the pool.

Missing Diagnostic Detail

To refine the recommendation, it would help to know whether your application explicitly handles the termination signal (e.g., SIGTERM) and initiates an orderly pool.end() before the process exits. If you already implement that, you can reduce the abruptness of connection loss, though the pool will still be rebuilt on the next start.

Practical Takeaway

Plan your pool for the maximum concurrent load you expect during normal operation, not for retention across scale‑to‑zero. Avoid a large min pool size; instead, allow the pool to grow on demand. Consider adding a brief pool.end() handler on SIGTERM if you want to give the database a graceful notice, but remember that the pool will be re‑created on the next cold start anyway.