Introduction

True multi-master replication across more than two PostgreSQL nodes is not something stock PostgreSQL gives you as a simple built-in checkbox. PostgreSQL has native physical replication and logical replication, but those are not the same thing as a turnkey conflict-resolving multi-master cluster. If you need more than one writable node, you need to choose carefully between redesigning the write topology and adopting a specialized replication product.

Start with What PostgreSQL Actually Provides

Native PostgreSQL gives you two main families of replication:

• physical streaming replication
• logical replication

Physical replication is fundamentally primary-to-replica. It is excellent for high availability and read scaling, but it is not multi-master.

Logical replication is more flexible and can be arranged bidirectionally, but that does not magically make a robust multi-master system appear. You still need to solve:

• conflict detection
• conflict resolution
• write ordering
• DDL handling
• network-partition behavior

That is why "can PostgreSQL do this?" and "should I build this with stock PostgreSQL?" are different questions.

Why More Than Two Writable Nodes Gets Hard Fast

Once three or more nodes can all accept writes, collisions become much more likely. Even if each pair of nodes can replicate changes, the real system question is what should happen when different nodes modify related rows at nearly the same time.

For example:

• node A updates row 42
• node B updates row 42
• node C receives the changes in a different order

Now you need a conflict rule, and that rule becomes part of your data semantics. There is no generic answer that is automatically correct for every application.

Native Logical Replication Is Useful, but It Is Not a Full Multi-Master Platform

PostgreSQL logical replication is publish-and-subscribe oriented. It is very useful for selected tables, migrations, and some bidirectional designs, but it is still an engineering toolkit, not a ready-made "many writable masters" cluster strategy.

A minimal publication/subscription example looks like this:

CREATE PUBLICATION app_pub FOR TABLE accounts, orders;

On another node:

CREATE SUBSCRIPTION app_sub
CONNECTION 'host=node1 dbname=app user=replicator password=secret'
PUBLICATION app_pub;

That is logical replication. It is not yet a full answer to "how do I safely run many writable masters?"

For Real Multi-Master, Use a Product Designed for It

If you truly need more than one writable PostgreSQL node, you should usually look at a solution that is explicitly built for that problem, such as EDB PGD/BDR-style technology, rather than trying to stitch together bare logical replication yourself.

Those platforms exist because the hard part is not shipping rows around. The hard part is managing distributed write conflicts and keeping the operational model survivable.

So the practical decision tree is:

• if one write leader is acceptable, use primary/replica architecture
• if bidirectional sync is limited and well understood, native logical replication may help
• if true multi-master across several nodes is a requirement, use a specialized product or rethink the architecture

Often the Better Answer Is Architectural, Not Replication-Based

Many teams ask for multi-master when what they actually need is one of these:

• regional reads with one write leader
• failover, not concurrent multi-site writes
• offline sync for a narrow subset of tables
• sharding by tenant or region

Those problems are often easier and safer to solve than general-purpose multi-master replication.

If you can partition writes by ownership or route all writes for one logical entity to one leader, you avoid an enormous amount of conflict complexity.

Common Pitfalls

• Assuming stock PostgreSQL has turnkey multi-master support just because logical replication exists.
• Treating row movement as the whole problem while ignoring conflict semantics.
• Designing for many writable nodes when the real need is high availability or better failover.
• Forgetting that DDL and operational procedures get harder in bidirectional or multi-master topologies.
• Adding a third writable node without first proving the two-node conflict story is sound.

Summary

• Stock PostgreSQL does not provide a simple turnkey multi-master solution for more than two writable nodes.
• Native logical replication is useful but is not the same as a full conflict-managing multi-master platform.
• True multi-master requires explicit conflict strategy and strong operational discipline.
• If many writable nodes are truly required, use a solution built for that purpose or redesign the write topology.
• In many cases, a single-write-leader architecture is the safer and more maintainable answer.