Leaderless vs. Leader-based replication
In leader-based (primary-replica) replication, one node is the primary for writes; replicas replicate from it and serve reads. Writes are ordered at the primary, simplifying consistency but creating a single point of write failure until failover. In leaderless replication, any node can accept writes; coordination (e.g. quorum, Raft/Paxos) ensures agreement. Leaderless can improve availability and write scaling but adds complexity. Vector databases may use either model for replication and metadata; the choice affects split-brain handling and disaster recovery.
Summary
- Leader-based (primary-replica): one node is primary for writes; replicas replicate from it. Writes ordered at primary, simpler consistency but single point of write failure until failover. Leaderless: any node can accept writes; coordination (quorum, Raft/Paxos) ensures agreement; can improve availability and write scaling but adds complexity.
- VDBs may use either for replication and metadata; choice affects split-brain and disaster recovery. Failover, quorum reads/writes, and how index replication fits each model vary by engine. Pipeline: leader-based—write to primary, replicate; leaderless—write to quorum, replicate. Practical tip: leader-based is simpler to reason about; leaderless when you need higher write availability.
Comparing replication models
Leader-based (primary-replica): one node is the primary for writes; replicas stream from it (WAL or segments). Writes are totally ordered at the primary, which simplifies consistency and conflict resolution. The primary is a single point of write failure until failover; a replica is promoted (often via Raft/Paxos or similar) when the primary is unavailable.
Leaderless: any node can accept writes; coordination (quorum writes, Raft/Paxos for metadata) ensures agreement. Reads may use quorum (read from multiple nodes, use latest) or read-from-one with eventual consistency. Leaderless can improve write availability and write scaling but adds complexity (conflict resolution, split-brain handling). Pipeline: leader-based—write to primary, replicate to replicas; leaderless—write to quorum, replicate. See replication for high availability, split-brain, and disaster recovery.
Failover and index replication
In leader-based systems, failover promotes a replica to primary; the new primary may need to replay or catch up. In leaderless, quorum reads/writes tolerate node failures without a single failover event. Vector index replication (large segments, index builds) may fit one model better depending on whether the engine streams segments or rebuilds on replicas. Practical tip: leader-based is simpler to reason about; leaderless when you need higher write availability.
Frequently Asked Questions
What is leader-based replication?
One node is the primary for writes; replicas replicate from it and serve reads. Writes are ordered at the primary, which simplifies consistency. Downside: primary is a single point of write failure until failover. See replication for HA.
What is leaderless replication?
Any node can accept writes; coordination (e.g. quorum, Raft/Paxos) ensures agreement. Can improve availability and write scaling but adds complexity. Choice affects split-brain handling and disaster recovery.
When to use leader-based vs. leaderless?
Leader-based: simpler operations and consistency; good when write load is moderate and failover is acceptable. Leaderless: when you need higher write availability and can manage quorum and conflict resolution. VDB index replication may fit one model better; check your engine.
How does failover work?
In leader-based systems, when the primary fails, a replica is promoted (often via Raft/Paxos). In leaderless, quorum reads/writes tolerate node failures. See disaster recovery and split-brain.