Glitch sleep/wake cycle vs. Node.js database connection pool: preventing intermittent exhaustion

When a Node.js project on Glitch enters its default idle sleep, the underlying process is terminated after roughly five minutes of inactivity. This abrupt kill can leave database connection pool state in an uncertain position, especially for pooled connections that wrap TLS sessions. Below is a breakdown of the likely explanation, confirmed facts, and the minimal steps needed to prevent intermittent pool exhaustion.

Likely explanation

Glitch’s sleep cycle sends a SIGKILL or equivalent signal to the Node.js process. Most database drivers will close the underlying socket on process termination, but they do not always return the connection to the database server’s idle pool in an orderly fashion. If the driver relies on reference counting and the pool object is garbage‑collected without an explicit drain, the server may still count the session as active. Repeated wake‑sleep cycles can therefore accumulate stale or “zombie” connections, making the pool appear exhausted even when query volume is low.

Confirmed facts

• Most Node.js drivers (pg, mysql2, etc.) honor OS process termination by closing the socket, but behavior varies with TLS session handling.
• TLS‑wrapped connections may leave session tickets on the server if the driver does not explicitly destroy or reuse them.
• Pooled connections are typically reference‑counted; if the pool is abandoned, the server may retain the session until the underlying socket fully closes.

Steps needed for this case

1. Set idleTimeoutMillis in the connection pool configuration to a value lower than Glitch’s sleep interval (e.g., 300000 ms = 5 min, or lower such as 60000 ms). This prompts the driver to proactively release idle connections before the process sleeps.
2. Register a process.on('SIGTERM') handler (Glitch can send SIGTERM during graceful shutdown) that calls pool.end() or driver‑specific cleanup to ensure all sockets are returned or closed before the process exits.
3. If using a driver that exposes a beforeExit hook, attach the same drain logic there as a fallback.
4. After the project wakes, issue a lightweight ping query (e.g., SELECT 1 for PostgreSQL, SELECT 1 for MySQL, or a simple db.adminCommand("ping") for MongoDB) to verify the pool is healthy before resuming full traffic.

Trade-offs of aggressive idle‑timeout tuning

Lowering idleTimeoutMillis reduces server‑side stale connections but increases wake‑up latency: the pool must recreate connections on the first request, which can add roughly 10–100 ms per new connection depending on the database and network latency. If Glitch triggers sleep via internal scheduling rather than an explicit SIGTERM, a SIGTERM handler may not fire in time, potentially causing request loss on the first post‑wake request.

To determine whether the above adjustments are necessary for your setup, please specify: the Node.js database driver in use (e.g., pg, mysql2, mongoose) and whether the Glitch project runs on the free tier with a hardcoded 5‑minute sleep window.