Why have the watch and pgbouncer since they both seem to do failover? about crunchy-containers

[jmccormick2001]

Hi, thanks for you question...this is indeed a case where you can pick and choose the deployment based on your use case. For folks that need connection pooling, I found a lot of them like pgbouncer. After offering that container up, it was pointed out to me that it offered a failover mechanism which I also exposed for folks to use.

I wrote crunchy-watch purely as a means to do a form of automated failover, that's its whole purpose and can be modifed pretty easily since it is just a bash script essentially. Next year, you will see crunchy-watch however get more sophisticated in terms of failover logic, it might move to a golang implementation and would be part of a more overarching postgres HA solution.

For connection pooling, you also have the pgpool container which does that as well. The killer feature of pgpool being however to route SQL statements to a master or replica based on the type of SQL statement (reads versus writes). Some like pgpool and some do not, but its there for folks to choose what they want to work with.

Stay tuned, around the January time frame I'm going to release an interesting container that
will offer an alternative to pgpool!

I probably need to revise the rather busy architecture diagram as well! :^))

cheers

[dsapala]

Excellent! Thank you for the detailed answer!!! Any hint as to what program that new container will be based on?

[jmccormick2001]

all new golang code :^)) Apache V2 license.

[dsapala]

Very cool. We'll definitely be watching to see that. Thank you for your contributions.