Hacker News new | ask | show | jobs
by sgarland 520 days ago
Pgbouncer is a connection pooler; it has nothing to do with replication.

That said, it’s not that hard to set up replication [0]. Properly tuning the various parameters, monitoring, and being able to fix issues is another story.

RDBMS is hard. MySQL is IMO the easiest to maintain up to a certain point, but it can still bite you in surprising ways. Postgres appears to be as easy on the surface, buoyed by a million blog posts about it, but as your dataset grows, so does the maintenance burden. Worse, if you don’t know what you should be doing, it just eventually blows up (txid wraparound from vacuum failures probably being the most common).

[0]: https://www.postgresql.org/docs/current/runtime-config-repli...
2 comments
orthoxerox 520 days ago
> txid wraparound from vacuum failures probably being the most common

Hopefully OrioleDB can upstream all the necessary changes soon. For those who don't know, it's a storage engine for Postgres that uses undo logs instead of vacuuming old records.

link
oliverrice 520 days ago
OrioleDB maintains a very small set of Postgres patches that are targeted for upstream. The storage engine that mitigates the need for vacuuming [1] is implemented in a standard Postgres extension, so that will still need to be installed by the Postgres host in order to take advantage of it.

But yeah, looking forward to that day too!

[1] https://www.orioledb.com/blog/no-more-vacuum-in-postgresql

link
ExoticPearTree 520 days ago
Yes, you are right, but I was thinking of the ease of having a high-availability setup and pgbouncer was the first thing that came to mind.

And yes, I read the documentation and it is still cumbersome to have an HA setup that is easy to maintain. This is what I mean and hope it is clearer now.

link