Show HN: Open source, logical multi-master PostgreSQL replication

You do not want multi-master. If you think you do, think again.

Source: I have operated a large multi-master Postgres cluster.

I imagined this position would depend almost entirely on the requirements of the project. Are you able to elaborate on why it's a universal "NO" for you?

That's just the point, it always sounds like a great idea to people not experienced in database operations.

The problem with the setup is you will have a data corruption issue at some point. It's not an "if" it's a "when". If you don't have a plan to deal with it, then you're hosed.

This is why the parent is turning around the burden of proof. If you can't definitely say why you absolutely need this, and no other solution will do, then avoid it.

Believe it or not, Mrs. Bigwheels is pretty experienced in the database department. I've seen multi-master HA architecture work out great for 10M+ DAU games, and many/most other cases where I wouldn't recommend it- as in it wouldn't even enter my brain, because the tradeoffs are harsh.

IME it comes down to considering CAP against the business goals, and taking into account how much it will annoy the development team(s).

If you follow "the rules" WRT to writes, it may fit the bill. Especially these days with beauties like RDS. But then again, Aurora is pretty awesome, and did not exist/mature until only ~5 years ago or so.

Definitely more of a wart than a pancea or silver bullet. Even still, I wouldn't dismiss outright, always keen to compare alternatives.

Overall it sounds like we're in the same camp, heh.

> I've seen multi-master HA architecture work out great for 10M+ DAU games

could you tell what kind of DB was that so we can understand if it is apple to apple comparison to multi-master PG?

It was a huge cluster (30 large servers in total) of MySQL with the MyISAM engine running in a Master-Master configuration. No foreign-keys allowed, the Apps were responsible for correctly enforcing data constraints.

Nowadays it seems the answer has somehow become "Pay MongoDB a ton of money for a support contract" and call it a day (Fortnite by Epic Games). Let's just say this isn't really my style, but somehow the game does work. To be real with you, keeping track of player scores, doing lobby matchmaking, and storing a few hundred or thousand items is pretty straightforward, even at "high-scale".

> MyISAM engine

MyISAM didn't support ACID transactions, thus can't be apples to apples comparison, its just very different niches.

There are plenty of distributed databases on the market today which could be used if you don't need ACID transactions.

Oops - I wasn't fully awake yet! It was using InnoDB.

MyISAM is mostly a huge "NOPE!" from me -_-