Sequelize pool idle limits vs database/proxy idle timeout alignment for low-traffic workloads

Answer

Confirmed facts: Sequelize’s pool.idle controls when its own connections are released. The value must be less than the smallest idle timeout (database or proxy) to avoid staleness. pool.min only limits the minimum number of connections kept by Sequelize, not by the transaction‑pooling proxy.

Likely explanation: In a low‑traffic workload the cost is driven by how long a connection stays open. If the database timeout is 30 s and the proxy timeout is 20 s, setting pool.idle to 15 s (or 10 s) ensures the pool discards idle connections before either side closes them, while still keeping a warm connection if pool.min > 0.

Steps to configure

1. Check Sequelize version and dialect – e.g., Sequelize 6.x with the PostgreSQL driver. Verify the default pool.idle (typically 10000 ms) and pool.min (0).
2. Obtain idle timeout values – query the database for its idle timeout (e.g., SHOW idle_in_transaction_session_timeout;) and read the proxy’s server_idle_timeout setting (e.g., pgBouncer = 20 s).
3. Set pool.idle to a value lower than the smallest timeout, typically 5–10 seconds less. Example: pool.idle = 15000 ms (15 s).
4. Choose pool.min based on latency tolerance: 0 eliminates warm connections and adds TLS/handshake latency on the first request; 1‑2 keeps a single warm connection, reducing that latency at a modest cost.
5. Validate – run a short load test, observe connection count in the database logs, and confirm no “stale connection” errors appear.

If you can provide the exact smallest idle timeout (database vs proxy), I can give a precise pool.idle value.