Architecture · data plane
The data plane.
Everything that serves your queries: the clusters. Each is three members in three zones that elect their own primary, fence themselves and fail over without anything else being up. The control plane builds and changes them; once they exist, they look after themselves.
What a cluster is
Every database is a cluster, and a cluster is a set of members, each on its own VM in its own zone. Two shapes are built and tested on AWS:
| Primary, replica, arbiter | Primary and two replicas | |
|---|---|---|
| Members | Two data members and an arbiter: a small VM that votes and stores no data | Three data members |
| Copies of the data | 2 | 3 |
| Synchronous replication | A commit waits for the replica. If the replica is lost the cluster can run degraded (see quorum and failover) | A commit waits for any one of the two replicas, so losing one replica does not block writes and loses no guarantee |
| Survives | Any one member or zone | Any one member or zone |
| Extra cost | A small arbiter VM | A second replica’s VM and disk |
| Status | Measured AWS chaos suite r1–r9, soak | Measured AWS suite p1–p5, no acknowledged write lost |
Clusters with more than two replicas (up to six) exist: the third replica onward does not vote. They are for reads and for more copies; they do not change what the voters can survive. Replacing such a non-voting member is not built.
What runs on a member
- PostgreSQL, in a container with fixed CPU and memory limits, on the persistent disk.
- The quorum sidecar: the Raft member that decides who is primary and fences a primary that cannot prove its role.
- The ops-agent: takes commands from the control plane (no SSH).
- The monitor agent, in its own container with its own limits and no route into the database’s network: it only pushes metrics and logs out (monitoring).
Members are reached only from inside the private network. Each cluster has its own application role (not a superuser), a replication role and a token for the members to use with each other, generated when it is created. There is no public address on any database.
The three deep dives
Creating a cluster
From one API call to three members in three zones, each step safe to repeat and to undo.
Quorum and failover
The members vote on who is primary, a primary that cannot prove it stops itself, and what two lost members do.
Minor upgrades
New machines from a newer image join beside the old ones; the old ones leave last.
What the data plane does not depend on
A running cluster needs its own three members, the cloud’s machines and disks, and the private network. It does not need the management server, the metrics or the Autopilot. The decisions that keep your data safe (who is primary, when to stop writing, when to promote) are made by the members, from their own state, and never use a metric. What the control plane adds is the work around the cluster: creating it, growing its disk, replacing a member, moving its DNS name after a failover.
Each part has its own failure modes, objectives and numbers; the three pages above give them. The numbers for the cluster as a whole, and what we will and will not promise, are on the reliability page.