Database High Availability
A managed database on one machine is a single point of failure. Turn on high availability and redu.cloud provisions three machines holding the same data, behind one load balancer address, with automatic failover when the writer dies.
EU-hosted, like everything else on the platform.
Available for
| Engine | High availability |
|---|---|
| PostgreSQL | Yes |
| ClickHouse | Yes |
| Redis, MySQL, MariaDB | Not yet. Single machine only, and a request asking for HA is rejected rather than silently ignored |
What it gives you
- Automatic failover. No operator, no ticket, no runbook. Another member takes over on its own.
- No lost writes. Across every failover test run so far, no write that had been acknowledged was missing afterwards.
- One address. Your connection string does not change when a machine dies.
- A machine that comes back rejoins by itself on PostgreSQL, as a caught-up replica rather than a second writer holding stale data.
Measured on the live platform, August 2026: a PostgreSQL machine deleted through redu was invisible to the client (279 writes, none failed). A machine whose power was cut cost zero failed requests and one 16.5 second pause while another member took over. On ClickHouse, destroying a member outright cost 2 of 1364 writes their acknowledgement, with no data lost: both of those writes had in fact been committed.
Full numbers, and the limits that go with them, are in the high-availability guide.
Pricing
Three machines instead of one, plus a load balancer. Roughly three times the single-machine cost. It is always an explicit opt-in, never turned on for you.
What it is not
- Not a backup. Replication copies a bad migration as faithfully as good data.
- Not extra throughput. Redundancy, not three times the writes.
- Not an automatic rebuild. Survivors keep serving when a machine is destroyed, but restoring the third member is not automatic for databases yet.