[1] https://mariadb.com/resources/blog/upgrade-now-announcing-my...
Multi-master is hard. The main issue is what to do with commit/replication lag. It's far "easier" if support for eventual consistency is ok with your use case. In some cases it's not. Also, the problems related to read-only lag can happen on multi-master instances. If somebody does a giant long running query on one of the masters, the target instance needs to hold the data state for the query, even if the underlying DB is getting updates. It also needs to still keep up with other masters. This means the whole cluster can slow down if the multi-master replication is synchronous. Depending on a variety of factors, that can chew up disk space, memory, etc.
There are ways of dealing with these issues (and others), but it comes with tradeoffs with performance, etc.
Multi master, from even a conceptual perspective, is incredibly complicated. Databases, transactions, consistency, parallelism are all very complicated.
It’s something that always seems promising at the start but as soon as maintenance and long term improvements enter the picture(ie integrating new Postgres versions), the complexity becomes too much.
which is not open source afaik
For example, with Multigres, you should be able to achieve true zero downtime major version upgrade by simply resharding [2]. With vanilla Postgres + pgBouncer, you can only achieve near-zero downtime (few seconds at most), though it's probably good enough for most use cases.
[2] https://multigres.com/docs#migrate-across-postgres-versions
According to they githyb (https://github.com/multigres/multigres) as of today (June 12th, 2026):
> Multigres is a Vitess adaptation for Postgres. The project is currently in the early stages of development.
Maybe it works, maybe it doesn't. I would start looking into it when it gets released as stable. Otherwise it's unfair.
At this point i wonder if i'll ever see that.