Intended use of database pools

[onwhenrdy]

While reading the documentation at https://rstudio.github.io/pool/articles/advanced-pool.html, I noticed that it might give the impression that increasing the number of connections in a database pool could help manage "spikes in traffic" (presumably in shiny or plumber applications).

However, since database pools and their underlying connections cannot be shared across process boundaries (e.g., via promise_futures), I am curious about how the intended use-case for database pools was envisioned, aside from the auto-connect feature. As far as I know, database operations (read/write) will always block. One could argue that different connections to the same database could, in theory, be checked out one after another. However, this seems to be an extremely esoteric usage pattern.

I think this information could benetif other (potential) users as well. Thx.

[jcheng5]

You’re right that needing multiple connections is for more esoteric use cases, at least until we get in-process async/non-blocking database queries in R. For today it would really be for transactions, with non-blocking/async steps between database queries. For example, SELECT FOR UPDATE, make an API call, UPDATE, COMMIT.

[onwhenrdy]

Thank you for the clarification and feedback.