Master Slave Replication vs Multi Master Replication

Two database replication topologies, one decision: do you want writes to go one place or everywhere? Master-slave (now primary-replica) routes every write through a single node and fans reads out to copies. Multi-master accepts writes on any node and reconciles the chaos afterward. Most teams reach for multi-master to dodge a single point of failure, then spend two years debugging write conflicts they never had before.

How they actually work

Master-slave designates one node as the primary. Every write lands there, then streams to read-only replicas via the binlog/WAL. Reads scale horizontally; writes do not. The model is brutally simple: there is exactly one truth, and replicas are eventually-consistent shadows of it. Multi-master lets any node accept writes, then propagates those changes to every peer and reconciles collisions. The appeal is obvious — no single write bottleneck, no single point of write failure, write-locality across regions. The cost is equally obvious once you ship it: two nodes can write the same row simultaneously, and now your database has to decide who wins. Master-slave never asks that question because it can't happen. That structural difference — one writer versus many — is the whole comparison. Everything else, availability, latency, complexity, is downstream of that one design choice. Pick the topology, inherit its problems.

Conflict handling: the real battleground

This is where multi-master earns its reputation. With concurrent writes to the same key, you need a resolution strategy: last-write-wins (silent data loss when clocks skew), CRDTs (great for counters and sets, useless for arbitrary business invariants), or application-level merge logic (you now maintain a distributed-systems paper in your codebase). Galera and similar do certification-based replication to abort conflicting transactions, which trades availability for safety — and still bottlenecks on hot rows because every write needs cluster consensus. Master-slave sidesteps all of it. One writer means serialized writes means no conflicts, full stop. Your transactions behave exactly like single-node Postgres because, for writes, they are. If your data has uniqueness constraints, foreign keys, or any invariant that spans rows, multi-master conflict resolution will betray you at the worst possible moment. The teams who love multi-master either have conflict-free workloads or haven't hit the conflict yet.

Availability and failover

Multi-master's pitch is availability: lose a node, keep writing. True — but it introduces split-brain, where a network partition leaves two halves each accepting writes, both convinced they're authoritative. Reconciling that is genuinely painful and sometimes lossy. Master-slave's honest weakness is the write path: kill the primary and writes stop until a replica is promoted. Without automation that's an outage. With Patroni, Orchestrator, or managed RDS/Aurora failover, promotion happens in seconds and the window is small. The dishonest framing is treating multi-master as 'highly available' and master-slave as 'not.' The accurate framing: master-slave concentrates the availability problem into one well-understood mechanism (failover) you can automate and test. Multi-master smears the problem across conflict resolution and partition behavior, which are far harder to test and reason about. You don't eliminate failure modes by going multi-master — you trade a simple one for several subtle ones.

Who should actually use multi-master

Narrow but real cases. Globally distributed apps where users in Tokyo and Frankfurt both need low-latency local writes — cross-region round-trips to a single primary are a dealbreaker. Append-mostly or conflict-free workloads (event logs, analytics ingestion, CRDT-friendly state) where collisions structurally can't corrupt invariants. Systems already built on multi-master-native stores like CockroachDB, Cassandra, or DynamoDB global tables, which bake reconciliation into the engine instead of bolting it onto MySQL. If you're hand-rolling multi-master on Postgres or MySQL to 'scale writes' or 'improve uptime' for a normal CRUD app, stop — you're buying a class of bugs to solve a problem read replicas and failover automation already handle. Multi-master is a specialist tool for genuine geo-distribution and conflict-tolerant data. It is not a default, and treating it as one is how teams end up with mysterious data divergence and a runbook nobody trusts.

Quick Comparison

Factor	Master Slave Replication	Multi Master Replication
Write scalability	Single write node; writes don't scale horizontally	Writes accepted on any node; scales geographically
Consistency model	Simple — one source of truth, no write conflicts possible	Complex — requires conflict resolution, risk of divergence
Operational complexity	Low; one writer, well-understood failover	High; split-brain, conflict logic, partition handling
Write availability	Depends on failover automation; brief gap on primary loss	Survives node loss but risks split-brain divergence
Geo write-locality	Poor; remote regions pay round-trip to primary	Strong; local writes per region

The Verdict

Use Master Slave Replication if: You want one source of truth for writes, easy read scaling, and a replication model your on-call engineer can reason about at 3am. This is 90% of applications.

Use Multi Master Replication if: You genuinely need writes accepted in multiple regions with local latency, can tolerate or engineer around conflict resolution, and have the operational maturity (CRDTs, vector clocks, app-level reconciliation) to handle divergence.

Consider: Failover automation. Master-slave's weakness is the write node — without automated promotion (Patroni, Orchestrator) a primary failure means downtime. Solve that before you flee to multi-master to 'fix' availability.

The Bottom Line

Master Slave Replication wins

For the overwhelming majority of systems, a single authoritative write node with read replicas gives you a clean consistency model, trivial conflict semantics (there are none), and operational sanity. Multi-master sounds like high availability until you meet last-write-wins data loss and split-brain. Reach for multi-master only when geographic write-locality is a hard requirement, not a vibe.

Related Comparisons