What's the recommendation for connection pooling?

[travishaagen]

What's the recommendation for connection pooling?

• https://github.com/r2dbc/r2dbc-pool appears to be unmaintained

Sometimes, we pool db connections, because they were expensive to create (slow).

Sometimes we want to control the maximum number of connections from each node to a server with limited connections available.

Thanks for any insights and suggestions!

[yhay81]

The practical recommendation is still to put r2dbc-pool in front of r2dbc-postgresql for a normal long-running application.

A reactive driver removes blocking threads; it does not make PostgreSQL connections free. Each physical connection still has a TCP/TLS/authentication startup cost and consumes a PostgreSQL backend process. A bounded pool also gives you the second property you want: a hard per-node concurrency limit.

r2dbc-pool has a low commit/release cadence, but it is a small, stable component under the R2DBC organization rather than a random abandoned alternative. The current README documents the supported limits/timeouts and resource lifecycle: https://github.com/r2dbc/r2dbc-pool#readme. Its latest Central release is 1.0.2.RELEASE, and Spring Boot continues to auto-configure it and expose spring.r2dbc.pool.* properties when it is present: https://docs.spring.io/spring-boot/3.4/appendix/application-properties/index.html#application-properties.data.spring.r2dbc.pool.enabled

For raw R2DBC, the shortest configuration is for example:

r2dbc:pool:postgresql://user:password@db:5432/app?maxSize=20&minIdle=0&maxIdleTime=PT30M&maxAcquireTime=PT5S

or build a ConnectionPoolConfiguration programmatically. Always close the logical Connection; with a pool, close() returns it to the pool. Dispose the pool at application shutdown.

Size it from the database budget, not from request concurrency. A useful upper bound is approximately:

maxSize per node <= floor((Postgres max_connections - admin/migration/headroom) / maximum app nodes)

Then reduce it if load tests show that more concurrent queries only increase latency. Set a finite maxAcquireTime so saturation fails visibly instead of building an unbounded wait queue, and use maxLifeTime/maxIdleTime values compatible with any proxy or load balancer in front of PostgreSQL.

If the database is already behind PgBouncer, you can use a smaller application pool, but I would not normally create a new physical R2DBC connection for every operation. Also check transaction-pooling compatibility before relying on session state or connection-scoped prepared statements.

[agorbachenko]

with existing reported defects r2dbc-pool is not usable in production

[yhay81]

That is a fair correction. I checked the currently open reports, including your cancellation reproducer r2dbc-pool#198, the same-physical-connection reuse report #211, and the Spring transaction leak report #219. Those are not merely cosmetic defects; cancellation/error-heavy reactive flows can make them correctness or capacity risks. I should not have stated an unconditional production recommendation.

For a deployment that cannot accept those risks, I would revise the recommendation to:

1. Put PgBouncer (or the platform's managed PostgreSQL proxy) in front of PostgreSQL.
2. Use the unpooled r2dbc:postgresql://... factory in the application.
3. Still bound application-side query concurrency (for example with a small semaphore/bulkhead), because an external pool does not by itself limit an individual application's demand.
4. Prefer PgBouncer session pooling unless the application has explicitly been tested with transaction pooling; transaction mode changes session-state and prepared-statement assumptions.

Opening a brand-new physical connection for every operation without an external pool is generally the least attractive option because it adds TLS/authentication and PostgreSQL backend churn. If neither r2dbc-pool nor an external proxy is acceptable, the conservative alternative is JDBC + a mature pool such as HikariCP, accepting the different threading/programming model.

So the answer depends on the workload and failure semantics: r2dbc-pool remains the standard integration, but the open cancellation/reuse issues are a valid reason to choose external pooling for production, especially when those Reactor patterns occur. Thanks for pointing out the missing caveat.