3 ms·

We ditched PgPool for PgBouncer for connection pooling from our webservers. PgPool tries to do way to much, and the documentation is horrible. PGBouncer been ro

We ditched PgPool for PgBouncer for connection pooling from our webservers. PgPool tries to do way to much, and the documentation is horrible. PGBouncer been rock solid compared to PgPool. I'd love for PgBouncer to poll the servers it's connected to and automatically talk to the master, so in case of master failure I would only have to promote a new master (and STONITH) and PgBouncer would auto-failover to the new master.

obviouslygreen 13y ago
Also using PGPool in production on one of our more complex projects here; it's been reliable over the last couple years with varying amounts of traffic. We haven't gotten what I'd call a lot of it, but what we do get generates fairly high DB load at times, and what problems we've had have not been due to PGBouncer.
jaytaylor 13y ago
Yes, PgBouncer is a little better but could still be improved upon in significant ways. E.g. Getting PgBouncer working with SSL connections- You have to do it through a specific version of stunnel. Then stunnel always has to be running in addition to PgBouncer. Not friendly or fun to setup.
- theatrus2 13y ago
  Out of curiosity, are you using Postgres with SSL for an offsite or multi-DC replica? Would switching to a site-to-site VPN be more efficient here?
  - stingraycharles 13y ago
    Wouldn't using site-to-site VPN be adding a SPOF just as well, namely the VPN server (and, in addition to this, make the VPN server a bottleneck for transfer speed) ?
    - vidarh 13y ago
      You can "easily" enough set up two VPN connections on separate pairs of machines and route to a virtual IP on each end and use ucarp or keepalived to have one or the other take over. It's not pretty, but it works. And the VPN server may very well become a bottleneck for transfer speed at some point, but most of us won't ever need to deal with a level of bandwidth where that's an issue.
  - jaytaylor 13y ago
    This was part of an attempt to improve our Django app, by using PgBouncer to do connection pooling with a Heroku database. Heroku requires SSL for all db connections. Site-to-site VPN would not have been an option in this instance, and in general I have had poor experience with them - Flaky SPOF, poor throughput, and so on.

obviouslygreen 13y ago

Also using PGPool in production on one of our more complex projects here; it's been reliable over the last couple years with varying amounts of traffic. We haven't gotten what I'd call a lot of it, but what we do get generates fairly high DB load at times, and what problems we've had have not been due to PGBouncer.

jaytaylor 13y ago

Yes, PgBouncer is a little better but could still be improved upon in significant ways. E.g. Getting PgBouncer working with SSL connections- You have to do it through a specific version of stunnel. Then stunnel always has to be running in addition to PgBouncer. Not friendly or fun to setup.

theatrus2 13y ago
Out of curiosity, are you using Postgres with SSL for an offsite or multi-DC replica? Would switching to a site-to-site VPN be more efficient here?
- stingraycharles 13y ago
  Wouldn't using site-to-site VPN be adding a SPOF just as well, namely the VPN server (and, in addition to this, make the VPN server a bottleneck for transfer speed) ?
  - vidarh 13y ago
    You can "easily" enough set up two VPN connections on separate pairs of machines and route to a virtual IP on each end and use ucarp or keepalived to have one or the other take over. It's not pretty, but it works. And the VPN server may very well become a bottleneck for transfer speed at some point, but most of us won't ever need to deal with a level of bandwidth where that's an issue.
- jaytaylor 13y ago
  This was part of an attempt to improve our Django app, by using PgBouncer to do connection pooling with a Heroku database. Heroku requires SSL for all db connections. Site-to-site VPN would not have been an option in this instance, and in general I have had poor experience with them - Flaky SPOF, poor throughput, and so on.