Go ahead.
Break it.
A server dies.
Nobody notices.
- 1Three nodes, one primaryYour app writes to the primary; two standbys keep a live copy.
- 2The primary failsHardware breaks. Within a second the cluster notices, agrees and fences it off.
- 3A standby takes overThe most up-to-date standby is promoted and your app reconnects to it.
- 4The old node healsIt comes back as a standby and catches up. About 4 seconds, no data lost.
Replicas can't save you
from yourself. This can.
A bad deploy or a mistyped command replicates instantly. Continuous backups let you rewind to the second before it happened. Drag the marker to before the mistake.
14:01:00
14:03:10
14:05:12
SELECT count(*) FROM customers;
ERROR: relation "customers" does not exist
Built for the
worst day.
Automatic failover
Health checks every second. A replica is promoted after three missed heartbeats, in under five seconds.
Split-brain protection
A node that loses quorum demotes itself. Two primaries can never accept writes at once.
Synchronous replication
Commits are confirmed on a second zone before your app hears "OK", so failovers lose nothing.
Multi-region standby
Keep a warm copy in another region and promote it if a whole region goes dark.
Tested backups
Every backup is restored automatically in a sandbox, because an untested backup is only a hope.
Seamless reconnects
A smart proxy points apps at the new primary, so there are no config changes and no restarts.
How available is
your Postgres today?
Our engineers will run a failure drill on your setup and show you exactly what would happen.