A database cluster is a group of database server nodes that work together as one logical database service, sharing or replicating data so that the service survives node failures, scales beyond a single machine, or both. In database replication, the cluster is the unit that replication, failover and membership operate on: the nodes, the copies of data they hold and the rules for which node accepts writes.
The term also has a narrower, engine-specific meaning. In PostgreSQL, a cluster is simply the set of databases managed by one server instance and one data directory. This page uses the broader sense of a multi-node cluster, which is the meaning in high-availability and replication design.
How a database cluster coordinates its nodes
A database cluster coordinates nodes through three mechanisms: data replication, membership and health detection, and request routing. Replication copies changes from the node that accepted them to the others, either by shipping the write-ahead log, by sending row-level change events, or through a consensus protocol such as Raft or Paxos.
Membership logic tracks which nodes are alive, usually with heartbeats every one to a few seconds and a failure timeout of several seconds to tens of seconds. When the writing node fails, the cluster runs a failover that promotes another node. To avoid two nodes both accepting writes, a split-brain, the decision requires a quorum: a majority of voting members, such as 2 of 3 or 3 of 5.
Routing hides the topology from applications. A proxy, virtual IP or cluster-aware driver sends writes to the current writer and can spread reads to replicas, so a failover changes the target without changing application configuration.
Architectures of database clusters
Database clusters differ mainly in where writes go and what nodes share. The architecture determines consistency, failover time and how far the cluster can scale.
| Architecture | How writes work | Main strength | Main limitation |
|---|---|---|---|
| Primary-replica | One primary accepts writes; replicas apply its log | Simple, well understood | Write capacity limited to one node |
| Multi-primary | Several nodes accept writes and exchange changes | Writes in several locations | Conflict detection and resolution |
| Shared-disk | Nodes access the same storage with distributed locking | Fast failover, no data copy | Storage is a single shared dependency |
| Shared-nothing sharded | Each node owns a subset of the data | Horizontal write scaling | Cross-shard queries and transactions |
| Consensus-replicated | Each write is committed by a quorum of replicas | Strong consistency with automatic failover | Higher write latency across distance |
Many production systems combine these patterns, for example a sharded cluster in which each shard is a small primary-replica or consensus group of three nodes.
Key parameters of a database cluster
Cluster behavior is governed by a small set of parameters that trade durability, latency and availability against each other. Choosing them deliberately matters more than the choice of product.
| Parameter | Typical values | What it affects |
|---|---|---|
| Node count | 3 or 5 voting nodes | Failures tolerated: 1 of 3, 2 of 5 |
| Replication mode | Asynchronous, semi-synchronous, synchronous | Data loss risk versus commit latency |
| Failure detection timeout | About 5-30 seconds | Failover speed versus false failovers |
| Recovery point objective (RPO) | Zero to several seconds | How much committed data may be lost |
| Recovery time objective (RTO) | Seconds to minutes | How long writes are unavailable |
Synchronous replication gives an RPO of zero but adds at least one network round trip to every commit, which is acceptable within a data center and costly between regions. Asynchronous replication keeps commits fast but means a failover can lose the most recent transactions, the amount bounded by replication lag.
Database cluster compared with related concepts
A database cluster is the whole group of cooperating nodes, while neighboring terms describe parts of it or one of its patterns. Confusing them leads to wrong expectations about failover and scaling.
| Term | Scope | Relation to a cluster |
|---|---|---|
| Primary-replica | Replication topology | One common way to organize a cluster |
| Read replica | A single node | A member that serves reads, not writes |
| Replication lag | A measurement | Delay between nodes inside a cluster |
| Sharding | Data distribution | Splits data across groups within a cluster |
| Backup | A copy in time | Protects against errors a cluster replicates |
The last row deserves emphasis: a cluster replicates mistakes as faithfully as valid writes. An accidental DELETE or a corrupting bug reaches every node within moments, so a cluster is never a substitute for backups and point-in-time recovery.
Operating risks and common mistakes
Most cluster incidents come from failover behaving differently than the team expected, not from the database software itself. Regular failover drills reveal these gaps before a real outage does.
- Running two voting nodes, which cannot form a majority after one failure; add a third node or a witness.
- Assuming asynchronous replicas are current and reading stale data right after a write.
- Setting failure timeouts too low, which causes flapping failovers during brief network hiccups.
- Placing all nodes in one rack or zone, so a single power or network fault takes down the cluster.
- Never testing promotion, so application connection handling fails during the first real failover.
Explained without jargon
A database cluster is like a team of librarians who each keep a copy of the same catalog. One librarian usually records new books, and the others copy each change. If the main librarian falls ill, the team quickly agrees on a replacement and work continues.
The benefit is that one failure does not stop the library. The catch is that copies can lag slightly behind, and a mistake written into the catalog is copied to everyone, so the library still needs separate archived copies.
A typical use case
An online ticketing service runs its order database as a three-node cluster spread across three availability zones in one region. The primary accepts all writes, one replica is semi-synchronous so every confirmed order exists on at least two nodes, and the third replica serves reporting queries. A connection proxy routes traffic and a consensus-based manager decides failovers with a 10-second detection timeout.
During a sales peak, the zone hosting the primary loses power. The two surviving nodes form a majority, promote the semi-synchronous replica and update the proxy. Checkout is unavailable for about 20 seconds, no confirmed order is lost, and customers who retried their payment complete the purchase without noticing anything beyond a brief delay.