Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

It's weird that PostgreSQL still doesn't have a proper, open source, general multi-master implementation.

At this point i wonder if i'll ever see that.



What about Multigres[0]? It builds on top of Postgres and adds HA (based on Flexible Paxos[1]), sharding, etc. They're still not production-ready, but I'm highly optimistic they will solve a lot of the problems Postgres have.

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.

[0] https://multigres.com/

[1] https://fpaxos.github.io/

[2] https://multigres.com/docs#migrate-across-postgres-versions


> What about Multigres[0]?

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.


pssst... we're 100% open source under the PostgreSQL license, with active-active multi-master replication for any topology from single-region HA to write-anywhere global. :-) try it out on the Downloads page on our site https://www.pgedge.com/download/enterprise-postgres for secure downloads, or check out Spock on GitHub (https://github.com/pgEdge/spock) and the Active Consistency Engine (https://github.com/pgedge/ace) to integrate the extension & tool yourself. Answers to common questions in our FAQ: https://www.pgedge.com/resources/faq#pgedge-distributed-post...


Do other RDBMSs have this? I genuinely have no clue. I've been fortunate enough to be able to get away with one primary and multiple secondaries at my largest usage of Postgres. Multi-master is the kind of thing I am fully out of my depth on, so I'm curious if there's a well defined path for implementation here or what.


Commercial RDBMS (oracle/mssql) have had it in some form for awhile, with pluses and minuses. Open source DBs have had bolt-ons, including BDR for pgsql.

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.


MySQL has Galera cluster for that.


More accurately, MariaDB has Galera for that. MySQL Galera is EOL in a few months [1], which is understandable given the change in ownership.

[1] https://mariadb.com/resources/blog/upgrade-now-announcing-my...


And Group Replication


And percona xtradb cluster


It has been tried many times. Good luck to pgdog, but there’s a reason these projects don’t stick.

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.


Well, not officially, but there are solutions for that. Like BDR (or Postgres Distributed nowadays) by EDB.


> Like BDR (or Postgres Distributed nowadays) by EDB.

which is not open source afaik




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: