PostgreSQL High Availability: What It Takes, What It Costs, and When Backups Are Enough

PostgreSQL high availability means a second server holding a live copy of the data, something that decides when the first server is dead, and something that sends connections to whichever one is currently primary. Postgres ships the replication and none of the rest, which is why HA is a project rather than a setting, and why most applications are better served by automated backups and a restore they have actually tested.

The official documentation has a whole chapter on it. The vendor guides all conclude that you need their product. What neither tells you plainly is how to decide whether you need any of it, so that comes first.

Table of contents

• What HA actually means, in numbers
• The three pieces every HA setup has
• Synchronous or asynchronous, and the trade nobody escapes
• What it costs
• When you do not need it, and what you need instead
• The managed middle
• How this fits the rest of the stack
• FAQ

What HA actually means, in numbers

Two numbers describe every availability decision. RPO, recovery point objective, is how much data you can afford to lose: the gap between the last safe copy and the moment of failure. RTO, recovery time objective, is how long you can afford to be down while you recover.

A single Postgres instance with nightly backups has an RPO of up to a day and an RTO of however long a restore takes, typically minutes to an hour depending on size. Add continuous WAL archiving and the RPO drops to seconds, because every transaction log segment is shipped off the box as it fills. The RTO is still a restore.

High availability is about the RTO. A standby that is already running, already has the data, and can be promoted in seconds turns an hour of downtime into a minute. That is the entire product. If your application can tolerate an hour of downtime once every couple of years, you may not need it, and it is worth being honest about that before reading the rest.

The three pieces every HA setup has

Whatever tool you use, the architecture is the same three parts.

1. The replica. Streaming replication ships the write-ahead log from the primary to one or more standbys, which replay it continuously. Postgres does this natively and well. A hot standby can also serve read queries, which is a nice side effect but not the point.
2. The decider. Something has to notice that the primary is gone and promote a standby. Postgres does not do this itself. Tools like Patroni or repmgr do, and the serious ones use a distributed consensus store, typically etcd or similar, so that two nodes cannot both decide they are primary. That situation is called split-brain and it is the failure mode that turns an outage into data corruption.
3. The router. Applications connect to a name or an address, and after failover that address has to point at the new primary. A virtual IP, a proxy like HAProxy or a connection pooler that knows the topology, or DNS with a short TTL. Each has a different failover delay and a different failure mode of its own.

Notice that the second and third pieces are not Postgres. They are a small distributed system you are now operating, and distributed systems fail in ways single servers do not.

Synchronous or asynchronous, and the trade nobody escapes

Replication can be asynchronous, where the primary commits and the standby catches up a moment later, or synchronous, where the primary waits for the standby to confirm before telling the client the commit succeeded.

Asynchronous is fast and, on failover, can lose the last few transactions that had not reached the standby. Synchronous loses nothing and adds the round trip to every write. It also means that if the standby goes away, the primary stalls, because it is waiting for a confirmation that will never arrive. You then need a second standby, or a rule that degrades to asynchronous, which reintroduces the data-loss window you were trying to close.

There is no configuration that gives you zero data loss, low write latency and tolerance of a single standby failure at once. Pick the two you need. Most teams that go to the trouble of HA pick asynchronous and accept a small RPO, because their RTO was the reason they started.

What it costs

The compute is the obvious part: at least two database servers of production size, and for a proper consensus quorum, three nodes for the decider. Call it two to three times the single-instance bill.

The less obvious part is the engineering. Someone has to build it, and someone has to test failover on a schedule, because an untested failover is a hypothesis. The teams that get burned are not the ones that never set up HA. They are the ones that set it up two years ago, changed the network since, and found out during the real outage that the promotion script needed a credential that had rotated.

Budget the recurring test, not just the build. Quarterly, on a staging copy that matches production, with the application pointed at it. If that sounds like more than the project is worth, that is useful information.

When you do not need it, and what you need instead

Most applications do not need multi-node HA. What they need is a much shorter list, and it is the list that HA projects tend to skip because they were busy with etcd.

• Automated backups on a schedule you did not have to set up, with retention you can see.
• Point-in-time recovery, or at least a backup interval short enough that the RPO is acceptable.
• A restore you have run. Once. Recently. Timed.
• Connection retry in the application, so a thirty-second database blip is a slow request rather than an outage.
• Monitoring that pages a human when the database is down, not just when it is slow.

One clarification worth making: a read replica is not high availability. It offloads reads, and it can be promoted by hand, but without the decider and the router it is a warm copy with a manual runbook. That is often a perfectly good place to be. Just do not call it HA on the status page.

The managed middle

Between a single server you patch yourself and a three-node cluster you operate, there is the managed instance, which is where most production databases for small and medium applications actually belong. The provider runs the engine, takes the backups, applies the patches, enforces the connection limit and keeps the instance on a private network with the application.

On RunxBuild that is a managed Postgres on the general plan ladder, from the $4 Dev plan for a development database to the $20 BasicPlus plan with 2GB of memory and upward from there, with backups, user management, connection limits and private networking to the services beside it. It is a managed single instance with backups, not a multi-node failover cluster, and a good managed database does not pretend to be one. What it removes is the 3am patching, the disk-full incident and the untested backup, which is the list above, which is the list most teams needed in the first place.

How this fits the rest of the stack

The right question is not whether you can build HA but what the downtime actually costs, and whether that number justifies two or three times the database bill plus the engineering to test it. The RunxBuild hosting calculator puts the managed-instance figure next to the service and storage costs, which is the honest baseline to compare a cluster against.

Useful related references:

• PostgreSQL 18: How to Upgrade Without Downtime
• SQLite vs PostgreSQL: Which One Your Project Actually Needs
• PostgreSQL Show Tables: \dt, pg_catalog, and information_schema
• Databases on RunxBuild

FAQ

What is PostgreSQL high availability?

A setup where a standby server holds a continuously replicated copy of the database and can be promoted to primary within seconds if the original fails. It needs three parts: streaming replication, a failover manager that decides when to promote, and a routing layer that sends connections to the current primary.

How does PostgreSQL failover work?

A failover manager such as Patroni or repmgr monitors the primary, usually through a consensus store, and when it decides the primary is gone it promotes a standby. Connections are then redirected by a virtual IP, a proxy or a DNS change. Postgres provides the replication; the deciding and routing come from tooling.

What is the difference between synchronous and asynchronous replication in Postgres?

Asynchronous replication commits on the primary first and ships the change to the standby a moment later, so a failover can lose the most recent transactions. Synchronous replication waits for the standby to confirm each commit, so nothing is lost, at the cost of write latency and a primary that stalls if the standby disappears.

Do I need high availability for my Postgres database?

Only if the cost of an hour of downtime, once every year or two, exceeds the cost of running two or three database servers plus regular failover testing. Most small and medium applications are better served by automated backups, point-in-time recovery, a tested restore and connection retry in the application.

Is a read replica the same as high availability?

No. A read replica is a continuously updated copy that can serve queries and can be promoted manually, but without an automatic failover manager and connection routing it is a warm standby with a runbook rather than an HA system. That is often fine, as long as the status page does not claim otherwise.