3 ms·
Alternatively, and specifically for PostgreSQL, if you can live with pgbouncer's constraints then you should be using it. It effectively self-manages an optimal
by zrail 8y ago
Alternatively, and specifically for PostgreSQL, if you can live with pgbouncer's constraints then you should be using it. It effectively self-manages an optimal shared connection pool for all of the application processes that connect to it.
- dijit 8y agoI would like to dissent. If your application is long lived you will get more benefit using the pooling functionality provided by the postgresql client libraries for your platform/language. pgbouncer is an intimidatory, and thus another thing to break- it has it's own constraints (mainly things like prepared statements will block a connection/cannot be reused) and its application should be well understood. For instance; I use it on a local socket on my zabbix master so that it can connect using a TLS encrypted pgsql socket. (something zabbix doesn't support). But for my main applications written in C++, I use connection pooling with nothing but the C++ client libraries. If you're bringing up and tearing down connections very often, then you will get a lot of benefit from pgbouncer, but in my experience these cases are limited.
- sb8244 8y agoComing from ActiveRecord gem, pgbouncer has been great. I'd say the real advantage is transaction level pooling, which will free up connections when they're not actively in a transaction (vs request level isolation). I don't see how this is possible across a large number of isolated servers without a cooperating agent like pgbouncer. I would advocate for pgbouncer at the DB ingress level and your languages connection pooler at the application level.