High-availability databases
A managed database normally runs on one machine. That machine is a single point of failure: if it dies, your database is down until it comes back.
High availability provisions three machines instead of one. They hold the same data, they elect a writer between themselves, and you reach them through a single load balancer address. Losing one machine does not take your database down and does not lose data you were told had been written.
Available for PostgreSQL and ClickHouse. Redis, MySQL and MariaDB are single-machine only today, and a request asking for high availability on those is rejected rather than quietly giving you one machine you believe is redundant.
High availability for databases is new. If you do not see the option on your account yet, ask us.
With an agent (MCP)
Connect the redu MCP, then ask in plain words.
Give me a Postgres that survives losing a machine.Your agent sets the high availability option (ha) on create_database or create_clickhouse. It triples what you pay, so a well behaved agent quotes the cost and waits for your go before it creates anything.
What it costs
Three machines instead of one, plus a load balancer. Budget for roughly three times the single-machine price, and check the current rates on the billing page.
This is the trade for redundancy and it is worth saying out loud before you turn it on. High availability is never enabled for you automatically, never inferred from the server size you picked, and never added as a “sensible upgrade”. You ask for it explicitly or you do not get it.
1. Create one
Console
Go to Managed → Databases → New database, fill in the same fields as a single-machine database, and turn on High availability before you submit.
Provisioning takes longer than a single machine, because the three members are brought up one at a time rather than all at once.
Full field reference: Managed Databases API.
2. Connect
Connect to the cluster’s load balancer address, never to one member’s IP. That address is what stays valid when a machine dies and another takes over. If you hardcode a member’s address, you have built a single point of failure on top of a cluster that does not have one.
Otherwise the connection details look exactly like a single-machine database, and every ordinary client, ORM and migration tool works unchanged.
postgresql://appuser:PASSWORD@CLUSTER_ADDRESS:5432/appTwo details worth knowing:
- PostgreSQL. Every member runs a connection pooler, and the load balancer sends you to a pooler rather than straight at the database. When the cluster promotes a new writer, the poolers repoint themselves, so your connection survives the change instead of being reset.
- ClickHouse. The load balancer keeps a given client on one member rather than spreading its requests around. That matters because replicas converge in a few seconds, not instantly, so a client bounced between members could otherwise watch its own write disappear and come back.
ClickHouse: create tables once
The database is created so that schema travels with the data. Issue your CREATE TABLE once, against the cluster address, and it reaches all three members by itself. You do not need ON CLUSTER, and a member that is refilled from empty gets its schema back on its own.
3. What happens when a machine dies
All of the numbers below were measured in August 2026 on the live platform, on three small machines with a client writing continuously throughout. They are measurements of specific runs, not a service level agreement. Bigger machines, bigger datasets and busier networks will move them.
PostgreSQL
| How the machine was lost | Writes attempted | Failed | Longest single write | Acknowledged writes lost |
|---|---|---|---|---|
| Deleted through redu | 279 | 0 | 0.13s, and that was before the machine was deleted | 0 |
| Hard power off, machine left down | 345 | 0 | 16.5s (every other write inside 0.2s) | 0 |
A machine deleted through redu was invisible to the client. Not one of the 279 writes failed and nothing even ran slowly: the longest wait in the whole run happened before the kill. That is the case the platform’s own tooling produces, because the machine is shut down properly and gets to hand over the writer role before it goes.
A machine that has its power cut cannot hand anything over, so the cluster has to notice on its own. That still cost zero failed requests, but one write sat waiting for 16.5 seconds while another member took over. We publish the 16.5 rather than rounding it down, because a query that hangs for sixteen seconds is something to design for rather than be surprised by.
Why the difference is detection, not repair. The writer holds a short-lived lease that it has to keep renewing. Death is the absence of a renewal, so a machine that vanishes is noticed after the lease expires, and nothing has to wait for network timeouts against a machine that will never answer. Promotion itself takes seconds. Shortening the lease would shorten the pause and buy false alarms on a momentary network blip, which is a worse trade than a rare 16.5 second wait.
A machine that comes back rejoins by itself. The powered-off machine was started again with no other action and returned as a caught-up replica of the current writer. It does not come back as a second writer holding stale data: a member that cannot prove it holds the lease steps down instead of accepting writes.
ClickHouse
One member of a three-member cluster was destroyed outright while a client wrote through the load balancer at about four writes a second, with no retry logic and a ten second timeout.
| Write attempts | 1364 |
| Client-visible failures | 2 |
| Rows actually present afterwards | 1364 of 1364 |
| Acknowledged writes lost | 0 |
| Next slowest request after those two | 9.5s, then 0.85s |
| Reads and writes for the rest of the run | uninterrupted, on the surviving two members |
Read that honestly: two requests failed, and no data was lost. Both were in flight to the member at the instant it was destroyed. They hung until the client gave up, so the client saw an error. The rows were there afterwards, which means the writes had actually been committed and what was lost was the acknowledgement, not the data.
So a client with no retry logic sees two errors during a machine loss. That is a blip affecting requests already in flight, roughly a twenty second window, and every request after it succeeded with the cluster down a member.
The consequence you have to design for: a timed-out insert may already have landed. If you retry it, you write it twice, because a plain table does not deduplicate. Give your inserts a deduplication key, or use a table engine that collapses duplicates, before you add retries.
4. What high availability does not do
The honest limits. Every one of these is a real gap or a real trade, not a hedge.
It does not rebuild a destroyed machine for you. Lose one member and the survivors keep serving, but getting back to three is not automatic for databases yet. An app cluster rebuilds a destroyed member unattended, typically within a few minutes. Database clusters are not enrolled in that yet, so a destroyed member is something you currently replace deliberately. A member that is switched off and switched back on is different, and rejoins by itself on PostgreSQL.
It is not a backup. Replication copies your mistakes as faithfully as your data. A bad migration, a dropped table or a DELETE without a WHERE reaches all three members immediately. Keep backups turned on.
It is not a performance feature. Three members give you redundancy, not three times the write throughput. Every write still has to land on the writer.
Losing two of three stops the cluster. Three machines survive one loss. With two gone there is no majority left, and a cluster without a majority will not promote a new writer. That is deliberate: it protects you from two machines both accepting writes and one of them being silently discarded later. We have measured the loss of one machine, not of two.
We do not yet publish a promise about the physical hosts underneath. Three separate machines is what protects you from a machine failing, and that is the case we have measured. We are not making a written guarantee that all three always land on three different physical hosts, because we have not finished proving it, and we would rather tell you that than let you assume it.
Replicas are a few seconds apart on ClickHouse. A read served by a member that has not caught up yet can be a couple of seconds stale. Keeping a client on one member hides this for that client, but a second client can briefly not see the first one’s write.
5. Writing an app that survives a failover
- Retry on connection errors. A failover is a brief error or a pause, not an outage, and a client that retries once rides through it.
- Set your timeouts above the recovery window, not below it. A ten second client timeout sits under both windows measured above. It is what turned two of the 1364 ClickHouse writes into errors, and it would have turned the 16.5 second PostgreSQL pause into one as well.
- Make writes idempotent if you retry them, especially on ClickHouse, where a timed-out insert may already have been committed.
- Never cache an individual member’s address. Resolve the cluster address and let the load balancer decide.
- Test it. Delete a member and watch your app. That is the only way to find out that your connection string points at one machine, or that your driver has no retry.
Related
- Managed Databases, creating and connecting to a single-machine database
- Database high availability, the short overview
- Clusters, the same idea for your application servers
- Backups, what high availability does not replace
- Managed Databases API