Why MySQL Still Beats Postgres for Multi-Master Redundancy

If a database outage stops your business, you want more than one copy of the data, and you want a surviving copy to take over on its own. PostgreSQL and MySQL can both do that. They get there in very different ways, and for a single-site cluster where every committed write must survive a server failure, the MySQL family still has the stronger open-source answer: three equal nodes, any of which can read and write.

This article compares that design with the usual PostgreSQL setup, a primary with replicas managed by Patroni, and explains where each one fits. Short version: Postgres is an excellent database, but it still has no built-in multi-master clustering, and that's the part that matters here.

Two ways to build redundancy

Primary/replica (PostgreSQL with Patroni): one server, the primary, takes all writes. One or more replicas receive a stream of changes from it and can answer read-only queries. If the primary dies, a replica is promoted to become the new primary.

Multi-master, also called active-active (MySQL-family clusters): every node holds a full copy and every node can accept writes. A transaction is agreed on by the cluster before it counts as committed. When a node dies there is nothing to promote; the others are already writable.

In the MySQL world, multi-master comes in two open-source flavors:

Galera Cluster, bundled with MariaDB and with Percona XtraDB Cluster (Percona's MySQL build). It has been in production use for more than ten years.
MySQL Group Replication (the engine behind Oracle's InnoDB Cluster), included in the free Community Edition.

How a three-node MySQL cluster works

Take Galera as the example. When you commit a transaction on any node, that node sends the transaction's changes (its write-set) to the other two before telling your application "done". All three nodes check each write-set in the same global order, a step called certification. If two nodes changed the same row at the same moment, one transaction wins and the other gets a deadlock error, which the application retries. Group Replication works the same way in principle, using the Paxos agreement protocol.

That gives you three properties a primary/replica setup can't fully match:

No lost commits on failover. Once your application sees a commit succeed, the change is already on the other nodes. Losing any one server loses nothing.
No promotion step. The surviving two nodes keep running as they were. Your proxy simply stops sending traffic to the dead one, usually within seconds.
Every node is a real copy. All three can serve reads, and any of them can take writes at any moment. A node that comes back after a crash or reboot re-syncs automatically from a healthy one.

Why three nodes, not two

These clusters decide by majority vote (a quorum). With three nodes, losing one still leaves two of three, a majority, so the cluster carries on. With only two, a failure, or just a broken network link between them, leaves one of two. Neither side can tell whether the other is dead or merely unreachable, so the survivor stops taking writes rather than risk split-brain: two halves accepting conflicting writes.

Galera offers a cheap compromise: two database nodes plus garbd, the Galera Arbitrator, on a small third machine. It votes but stores no data. Three full nodes is still the better standard, because:

a rejoining node can copy its data from one survivor while the other keeps serving traffic;
all three nodes serve reads;
you can patch and reboot one node at a time without ever dropping to a single copy.

Keep the count odd (3 or 5; a fourth node adds latency without surviving any extra failures), put the nodes on separate hosts, racks or availability zones, keep them close together on the network, and size them the same: the cluster runs at the speed of its slowest member.

How PostgreSQL with Patroni compares

Patroni is the standard open-source tool for automatic failover in PostgreSQL, and it does that job well. Looking at it next to a three-node MySQL cluster shows the gaps:

Replicas are read-only. Only the primary takes writes. Long reports on a replica can also be cancelled when they clash with incoming changes.
Failover is a promotion. Patroni has to notice the primary is gone (its leader lock expires, 30 seconds by default), pick the best replica and promote it. Expect a write outage of roughly 10 to 30+ seconds, depending on tuning.
Replication is asynchronous by default. A transaction can be committed on the primary but not yet on any replica. If the primary dies at that moment, that transaction is gone after failover. Patroni's maximum_lag_on_failover setting limits how much can be lost, but not to zero.
More moving parts. Patroni needs a separate consensus store (etcd, Consul or ZooKeeper), normally three more members. A typical production setup is three etcd nodes plus two or three Postgres servers, and the old primary usually needs pg_rewind before it can rejoin.

To be fair: you can make Patroni lossless. Turning on synchronous_mode makes the primary wait until a standby confirms each commit, so no committed transaction is lost on failover. Even then you still have one writable server, a promotion step and a separate consensus cluster. That's the core difference: Patroni makes a single-writer database fail over well, while Galera and Group Replication remove the single writer altogether.

Doesn't Postgres have multi-master now?

Not in the core database. PostgreSQL 16 added bidirectional logical replication, and PostgreSQL 18 detects and logs conflicts, but it doesn't resolve them; a conflict that raises an error stops replication until someone fixes it by hand.

Two open-source extensions fill the gap, and both arrived in 2025:

Spock from pgEdge, relicensed under the PostgreSQL License in September 2025.
pgactive from AWS, open-sourced under Apache 2.0 in June 2025.

Both are asynchronous: each node commits locally and ships the change afterwards. When two nodes change the same row, a rule such as "last update wins" picks the result after the fact, which means one of those writes quietly disappears. Normal integer sequences aren't replicated either, so you need UUIDs or special ID generators. That design suits geographically spread systems that can live with eventual consistency. It isn't the "every commit is everywhere" guarantee you want for a critical single-site database, and it's far younger than Galera.

Side by side

	3-node Galera / Group Replication	Postgres + Patroni	Postgres + Spock / pgactive
Writable nodes	All	One (primary)	All
Committed data on failover	Never lost	Can be lost (async default); safe with `synchronous_mode`	Recent writes can be lost or overwritten
Failover	No promotion; seconds	Promotion; ~10–30+ s	No promotion
Write conflicts	Detected at commit; loser retries	Not possible (one writer)	Resolved later by rule
Extra infrastructure	None (proxy recommended)	etcd/Consul/ZooKeeper cluster	None
Open-source track record	10+ years	Mature	New (2025)

The honest caveats

Multi-master isn't free. Before you build one, know these limits:

It doesn't scale writes. Every node applies every write. Three nodes give you redundancy and more read capacity, not three times the write throughput.
Every commit waits for the network. Keep the nodes in one data center or region. Across a WAN, commit times climb sharply.
Hot rows cause conflicts. If many sessions update the same rows on different nodes, you'll see frequent deadlock errors. Most teams write to one node at a time and fail over to another, which keeps the redundancy and avoids the conflicts.
Reads elsewhere can trail by milliseconds. A commit is certified everywhere instantly but applied in the background. If your app must read its own write from a different node, set wsrep_sync_wait (Galera) or the group consistency level (Group Replication).
Schema changes need care, very large transactions perform badly, and only InnoDB tables are replicated. Group Replication in multi-primary mode adds its own limits, such as no cascading foreign keys, so Oracle steers users toward its single-primary mode.

A practical layout

Three MariaDB or Percona XtraDB Cluster nodes running Galera, on separate hosts in the same site, with equal CPU, RAM and disk.
ProxySQL (open source) on each application server or on a pair of hosts sharing a floating IP via keepalived. It health-checks the nodes, sends writes to one node at a time and spreads reads across all three. If you choose MySQL Group Replication instead, MySQL Router does the same job.
Your application connects to the proxy, never to a database node directly, and retries a transaction when it gets a deadlock error.
Backups still matter. A cluster faithfully copies an accidental DELETE to every node within milliseconds. Keep regular, off-site backups you have actually restored.

A minimal Galera section of the MariaDB configuration on each node looks like this:

[mysqld]
binlog_format            = ROW
default_storage_engine   = InnoDB
innodb_autoinc_lock_mode = 2

wsrep_on                 = ON
wsrep_provider           = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name       = app_cluster
wsrep_cluster_address    = gcomm://10.0.0.11,10.0.0.12,10.0.0.13
wsrep_node_address       = 10.0.0.11
wsrep_sst_method         = mariabackup

When Postgres is still the right choice

This isn't a case against PostgreSQL. Pick it when you need what it does best: strict SQL, rich data types like JSONB, extensions such as PostGIS and pgvector, or transactional schema changes. If a few seconds of write downtime on failover is acceptable, Patroni with synchronous_mode is a solid, well-understood setup. And if you need local writes in several regions, Postgres with Spock is now a real open-source option, as long as you design around eventual consistency.

The bottom line

For one critical database in one location, where every node should be able to take over instantly and no committed transaction may be lost, three MySQL-family nodes running Galera or Group Replication remain the most proven open-source design. PostgreSQL with Patroni gives you good failover for a single writer; it doesn't give you three equal, writable copies.

Planning a database cluster, or not sure your current one would survive losing a server? Get in touch and we'll help you design and test it.