Or just MySQL. Popular choice, unpopular opinion. I trust it more because it gives me a tried and tested path when I need replication (which tends to happen rather early). My understanding is that Postgres replication is not nearly as battle-tested.
"Postgres replication is not nearly as battle-tested." - I maintain about 2,000 Postgresql database clusters at work, in various replication configurations. Over the past several years we have had maybe a handful of issues with replication, and each one related in some way to infrastructure problems. Dozens of those systems are doing over 20k transactions per second, so they are pushing decent data through the WAL stream.
The problem is in the philosophy regarding data vs application in the two products. MySQL treats the data as king and allows any application to turn off safety measures. PostgreSQL treats data constraints as king and expects apps to honor them.
This means that the two aren't really competitors any more than either is a competitor to SQLite. MySQL is a fine choice when you want a dumb store for your data and trust the application to do all necessary checks. PostgreSQL is a lot more pedantic and that makes it better when you want multiple front-ends to the same data.
The only real problem with PostgreSQL replication is the plethora of choices surrounding it.
PostgreSQL replication has plenty of major users who stress it quite a bit, and it is over 6 years old by now and a lot of the underlying infrastructure is older than that. The direct predecessor of the current replication (warm standby with transaction log file shipping, usually with rsync) is from 2006. It was a lot of work to set up right but once we got it up running it worked flawlessly for our use case.
So with its over 10 years of history (6 of those in its current form) the built-in replication has gotten quite a bit of testing.
Can you give me a link? Searching for how to deploy it turns up dozens of guides of varying age that refer to different projects of different levels of maturity.
