4 ms·
If you’re handling that many connections, does pgbouncer really add that much complexity? Surely at that scale, pgbouncer is less complex than alternative scali
by qeternity 6y ago
If you’re handling that many connections, does pgbouncer really add that much complexity? Surely at that scale, pgbouncer is less complex than alternative scaling options (replicas, caching, etc). We run it in production and hardly consider ourselves experts in pgbouncer.
- 1996 6y agoBefore pgbouncer, I was running with 6000 active connections, each of them doing insertions. I fail to see how replicas can help if your input comes from that many clients doing writes, each already having an internal pool. I tried various other things, like an unlogged table on the input side, but nothing helped much. I have tested with and without pgbouncer, and the case isn't as clear cut as it seems. It helps a bit, but it adds complexity. This complexity is not readily apparent, but you have to separately manage the userlist, you must not get your auth types out of sync (md5/scram), and so on... The only reason pgbouncer stays is that I don't want to mess with it again, but it's death by a thousand paper cuts, enough to complexify deployment and updates to a point where I'm thinking of calling it quit and using a different database in front of postgres.