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

Goal

For a low-traffic Sequelize application, the goal is to minimize retained database connections and associated cost without causing stale connection errors when the database server or an intermediary proxy enforces its own idle timeout.

Uncertainty

Sequelize exposes a constructor pool option shared across dialects, including min, max, idle, and acquire. Exact defaults and behavior are version-sensitive and should be confirmed for the installed major version and dialect. Setting min: 0 allows Sequelize to release idle connections after the configured idle period, but if the database or proxy idle limit is shorter, a pooled connection may be stale when reused. Keeping a small min > 0 preserves warm connections at the cost of always-on database sessions. When a transaction-pooling proxy sits between Sequelize and the database, connection lifetime and count semantics may differ from a direct connection, so end-to-end behavior is not obvious from Sequelize settings alone.

Questions

1. For a given Sequelize major version and dialect, how should pool.idle be chosen relative to the database server and any proxy idle timeout to minimize retained connections without introducing stale-connection risk?
2. In a transaction-pooling proxy deployment, does Sequelize's pool.min control client-side connections, proxy-side connections, or both, and how does that affect total cost?
3. What is the practical latency trade-off between min: 0 and a small min > 0 when the first request after idle must establish a new connection through TLS and the network path?