Raise ActiveRecord connection pool size versus extend checkout_timeout to mitigate intermittent thread wait spikes under concurrent load

Question

Goal: Determine whether intermittent ActiveRecord connection pool exhaustion in a Rails application should be addressed by increasing the per-process connection pool size or by extending the checkout_timeout threshold, given that thread concurrency and database connection limits interact non-linearly across processes.
Constraints and uncertainty: Pool size is per process; total database connections equal pool size multiplied by the number of running processes (e.g., Puma workers, Sidekiq workers), which can silently exceed PostgreSQL's max_connections. checkout_timeout only controls wait duration before raising ConnectionTimeoutError and does not free held connections. Rails version defaults and thread consumers (especially with async_query_executor in Rails 7.1+) affect which threads hold connections. Metrics such as pool busy/waiting counts and database activity views often cannot distinguish between capacity shortage and connection-holding leaks or long-running transactions.

Is the observed exhaustion primarily driven by concurrent thread count surpassing the configured pool across all processes, or by specific code paths retaining connections beyond request boundaries?
  Would raising the pool size risk hitting the database's max_connections limit before alleviating the symptom, and would extending checkout_timeout merely defer the error while allowing accumulating wait times?
  How does the deployed Rails version's treatment of per-process pooling and async query execution influence the validity of each approach?

Raise ActiveRecord connection pool size versus extend checkout_timeout to mitigate intermittent thread wait spikes under concurrent load

0 answers

Your perspective belongs here.

0 question comments