NullPool connection behavior and cost limits for low-traffic SQLAlchemy workloads
0 reputation · 08 Sept 2021, 08:09 UTC
A low-traffic application needs to reduce database connection costs without violating response-time expectations. SQLAlchemy’s default QueuePool maintains a fixed pool_size of connections plus overflow, which can keep idle sessions open on the database side during long idle periods.
NullPool is a documented alternative that opens a connection on checkout and closes it on return, removing idle connections. The documented trade-offs involve connection-setup latency per request from TCP/TLS/auth handshakes, and the interaction with settings such as pool_recycle and pool_pre_ping for stale-connection resilience in intermittent workloads.
The unresolved decision is whether the latency cost of fresh connections under NullPool is acceptable for the workload’s response-time budget versus the savings from releasing idle connections.
What is the documented connection lifecycle difference between QueuePool and NullPool for sporadic requests? Is the per-checkout latency of NullPool bounded by connection establishment only, or are there additional documented limits? Under low traffic, does pool_pre_ping introduce a measurable per-checkout cost compared with pool_recycle?
sqlalchemy