PostgreSQL High Availability: Standbys, Failover & Read Replicas

PostgreSQL high availability is an operating architecture that keeps database service available through selected primary failures by maintaining a promotion-ready standby, detecting failure, routing traffic, and reconnecting applications safely.

The important distinction is failover readiness. A replica can be healthy enough for reporting but still be a poor HA target if it is too far behind, cannot be promoted safely, or the application cannot reconnect after promotion. PostgreSQL HA therefore includes more than replication itself: detection, promotion, fencing, routing, lag control, application behavior, and post-failover recovery all matter.

Raff Technologies supports 3,000+ customers and 15,000+ VMs. Raff's current managed PostgreSQL design deliberately separates availability from read scaling: HA uses a synchronous standby in a separate zone with automatic failover, while read replicas are a separate scaling option. This guide explains when those roles should remain separate and what small teams should prove before calling PostgreSQL highly available.

A PostgreSQL standby becomes an HA system only when the team can detect failure, promote safely, prevent the old primary from accepting writes, redirect clients, and restore redundancy afterward.

PostgreSQL high availability starts with the failure you need to survive

High availability is primarily a continuity decision. PostgreSQL's documentation describes HA as allowing a second server to take over quickly if the primary fails.

That goal is narrower than disaster recovery and broader than simply creating a replica.

A production team should first define which failures the HA design is expected to absorb:

• primary database process failure;
• primary host failure;
• loss of the primary's local storage path;
• maintenance that requires primary replacement;
• network isolation affecting one database node;
• a zone-level failure when the architecture spans separate zones.

The design also needs a continuity target: how quickly must writes resume, and what user impact is acceptable while the application reconnects?

This page does not treat HA as backup or historical recovery. Those controls solve different failure modes. For that boundary, use PostgreSQL Replication vs Backups vs Snapshots.

The HA question here is simpler: if the current primary becomes unusable, can the system establish exactly one safe writable primary and move application traffic to it predictably?

An HA standby and a read replica have different jobs

A PostgreSQL standby can serve more than one purpose, but the operating priorities change with the role.

A hot standby can accept read-only queries while replaying changes from the primary. That makes read scaling possible, but it does not make every read replica an appropriate failover target.

PostgreSQL documentation notes that a hot standby can return data that is behind the primary because replay is not necessarily instantaneous. It also recommends different delay priorities depending on whether a standby exists primarily for HA or for long-running queries.

That distinction matters in small architectures. A reporting replica may be valuable even when it is seconds or minutes behind. An HA standby needs much tighter readiness because promotion changes it from a read-only copy into the new source of writes.

A useful rule is:

Use read replicas to scale reads. Use an HA standby to protect write continuity. Treat one replica as both only when its lag, query workload, promotion behavior, and recovery process are deliberately designed for both roles.

Failover is more than promoting a standby

Promotion is only one event in a complete failover path.

A production failover normally has to solve several problems in order:

1. Detect the primary failure. The system must distinguish a real failure from a short network interruption or monitoring problem.
2. Select the standby that may become primary. The candidate must be healthy and sufficiently current for the continuity objective.
3. Fence or isolate the old primary. A previous primary that later reappears must not continue accepting writes as if it were still authoritative.
4. Promote the new primary. The standby becomes writable.
5. Redirect database traffic. Applications need an endpoint or routing mechanism that resolves to the new writer.
6. Reconnect safely. Connection pools, workers, and scheduled jobs must recover without creating a retry storm.
7. Validate service state. The team must prove that new writes succeed and critical application workflows still behave correctly.
8. Restore redundancy. After failover, the topology is degraded until another standby is available.

PostgreSQL itself provides the database mechanisms required for standby operation and promotion, but its documentation explicitly notes that PostgreSQL does not provide the complete external system needed to detect a primary failure and notify a standby automatically.

That is one of the clearest managed-versus-self-hosted boundaries. Self-hosted HA requires the team to own the orchestration around PostgreSQL, not only PostgreSQL configuration.

The old-primary problem is especially important. If a promoted standby accepts writes while the previous primary also returns and accepts writes, the architecture can split into two competing writable histories. A failover design therefore needs a reliable mechanism to isolate the failed or stale primary before normal write traffic continues.

Replication lag changes failover risk

Replication lag is the distance between the current primary state and what a standby has replayed.

For HA, lag matters because promotion converts the standby's current state into the new writable database state. If the standby is behind, some recent work may not be present after promotion, depending on the replication and acknowledgement model.

The HA page should monitor lag as a readiness signal rather than treating it as a generic performance metric.

Useful questions include:

• Is the standby receiving changes from the primary?
• Is it replaying those changes quickly enough?
• Is lag growing during normal traffic?
• Does a long-running read query delay replay?
• Is the standby still inside the business's acceptable failover window?
• Would the team allow promotion at the current lag level?

Do not respond to growing lag by focusing only on the replication number. The cause may be storage pressure, network delay, heavy queries on the standby, insufficient compute, or a workload spike on the primary.

The deeper synchronous-versus-asynchronous durability trade-off already belongs to PostgreSQL Replication vs Backups vs Snapshots. For HA operations, the practical rule is that promotion eligibility needs a defined lag threshold and an operator or platform decision for what happens when that threshold is exceeded.

Application behavior determines whether database HA is usable

A database can fail over correctly while the product still appears unavailable.

Applications must be designed for the fact that a failover interrupts existing connections and may terminate transactions that were in progress. The application then has to reconnect to the correct writer and decide which failed work is safe to retry.

HA readiness should include application decisions for:

• Writer discovery: how does the application reach the current primary after promotion?
• Connection retry: how quickly should clients retry, and when should they stop?
• Backoff: can hundreds of workers reconnect without creating a thundering herd?
• Transaction uncertainty: how does the application handle a connection lost near commit time?
• Idempotency: can jobs or requests be repeated without creating duplicate business effects?
• Read routing: do read replicas have separate endpoints from the writable primary?
• Cache behavior: can stale cached state create incorrect behavior after writer promotion?
• Health checks: does application health depend on successful writes or only on process uptime?

Connection pools need particular attention because they may retain broken connections after the writer changes. Pool configuration itself belongs in PostgreSQL Connection Pooling: PgBouncer, Limits & SaaS Workloads; the HA requirement is simply that the pool can discard failed connections and establish new ones against the current writer without overwhelming it.

Database failover is complete only when application writes have resumed against the new primary and failed in-flight work has a safe retry policy.

The decision framework separates HA from read scaling

Not every production PostgreSQL workload needs a dedicated HA standby, and not every workload that needs read replicas needs automatic failover.

Choose HA when interruption from primary failure creates enough customer, revenue, or operational impact to justify continuous standby capacity and failover complexity.

Choose a read replica when the main problem is read workload distribution and eventual consistency is acceptable for those reads.

Choose both when the database needs rapid writer continuity and independent read scaling.

Choose neither when the workload can tolerate a tested restore-and-restart process and the extra moving parts would create more operational risk than value.

A practical sequencing rule for small teams is: prove recovery first, make application reconnects safe, then add HA when the continuity target requires it.

Managed and self-hosted PostgreSQL change who owns failover

The database concepts are the same, but the operating responsibility changes substantially.

Raff Managed PostgreSQL currently supports PostgreSQL 14, 15, and 16. Its HA option uses a synchronous standby in a separate zone with automatic failover, while read replicas are offered separately for workloads that need read scaling.

That separation reflects an important production decision: the standby protecting writer continuity should not automatically inherit every analytical or read-scaling responsibility.

For self-hosted PostgreSQL on a Raff VM, the team gains deeper control over topology and software choices, but it must also own detection, promotion orchestration, fencing, routing, monitoring, standby rebuilds, and failover exercises.

Failover testing proves whether the architecture is actually ready

An HA diagram is not evidence that failover will work.

A useful failover exercise should prove the whole service path, not only that PostgreSQL can promote a standby.

Validate these outcomes:

• Primary failure is detected within the expected window.
• The intended standby is eligible for promotion.
• Replication lag is inside the accepted threshold before promotion.
• The old primary cannot continue serving writes.
• The promoted standby accepts new writes.
• Application traffic reaches the new writer.
• Connection pools discard unusable connections and reconnect.
• In-flight transactions and retries behave as designed.
• Background workers and scheduled jobs recover safely.
• Read replicas continue using the correct upstream topology.
• Monitoring identifies the new primary correctly.
• A replacement standby can be created and redundancy restored.
• The measured interruption matches the continuity target.

PostgreSQL's failover documentation explicitly recommends regular switching where appropriate because planned role changes help test whether failover procedures actually work.

From an operating perspective, the strongest HA evidence is not “a standby exists.” It is a recently tested transition from one writable primary to another, with the application still producing correct writes afterward.

Conclusion

PostgreSQL high availability is a failover-readiness problem, not simply a replication feature.

A usable HA design needs a standby whose role is clear, a safe promotion decision, protection against the old primary returning as a writer, traffic redirection, application reconnect behavior, lag monitoring, and a process for restoring redundancy after failover. Read replicas can support HA only when their promotion readiness is designed and tested; otherwise, they should remain read-scaling components.

For the broader PostgreSQL operating model, return to PostgreSQL for SaaS Apps. For the separate historical-recovery layer, use PostgreSQL Replication vs Backups vs Snapshots.

Sources

• PostgreSQL: High Availability, Load Balancing, and Replication
• PostgreSQL: Failover
• PostgreSQL: Hot Standby
• Raff Managed PostgreSQL
• Product details reviewed: 2026-08-12