Connection pooling

A connection pool is a cache of database connections that can be reused. When a request comes in from a client, an available connection from the pool is given for that request or transaction.

In contrast, without any connection pooling, the client has to reach out to the database to establish a connection. Opening new connections can impact availability and performance — in PostgreSQL, the server "forks" or creates a new process, and could use up available resources as well as prevent new connections from being established. Connection pooling helps mitigate these issues and ensure that your applications can scale.

Crunchy Bridge connection pooling settings

Crunchy Bridge uses pgBouncer for connection pooling. By default, PgBouncer instances on Bridge are run in transaction pooling mode. See the PgBouncer How To page for guidance on how to enable and configure it on Crunchy Bridge.

Do I need connection pooling?

Connection pooling is especially helpful when you have a high number of connections from your application, often in a client-side pool or via multiple threads/processes on from your webserver.

You can run the following query to determine if you would benefit from connection pooling:

SELECT count(*),
       state
FROM pg_stat_activity
GROUP BY 2;
 count |             state
-------+-------------------------------
     7 | active
    69 | idle
    26 | idle in transaction
    11 | idle in transaction (aborted)
(4 rows)
Copy

If you see a high number of idle connections relative to active ones, then using connection pooling is strongly recommended.

Note that you can also set the max_connections configuration parameter higher than the default of 500 if desired. That change requires a Postgres restart, and that you have set the same or greater max_connections value on any replicas.