DBAtlas · Database operations atlas

Decision: which HA/DR solution?

Choosing a high availability and disaster recovery solution starts not with technology but with the balance between business requirements (RTO/RPO), the need for geographic distribution and cost. Starting from your tolerance for downtime and data loss, this tree points you to the right approach among synchronous replicas, asynchronous standbys, automatic failover clusters and backup+PITR.

What is your data loss tolerance (RPO)?

Start with the hardest constraint: in a disaster, how many seconds of data can you afford to lose? If zero data loss (RPO=0) is required, synchronous replication is mandatory; if a few seconds/minutes are acceptable, asynchronous solutions and cheaper approaches open up. The RPO target usually drives every other decision.

  • Zero data loss is mandatory (RPO = 0)
  • A few seconds/minutes of data loss is acceptable

Is automatic, fast takeover (low RTO) also required?

You want zero data loss; but how quickly must you be back up when the primary goes down? Automatic failover within seconds, or is a short manual intervention window acceptable? This determines the difference between a plain synchronous replica and a fully automated cluster.

  • Automatic failover within seconds is required
  • Manual/planned takeover is enough; zero loss comes first

Is a different region/geography required (DR)?

If some data loss is acceptable, the real question is the scope of resilience: must you be protected against losing an entire data center/region, or is protection against a single node failure in the same region enough? If geographic distribution is required, an asynchronous standby comes to the fore; if not, cost-first options are evaluated.

  • Yes, a separate region against geographic disasters is mandatory
  • No, budget and simplicity come first

Can you accept a long recovery time (high RTO)?

You are staying in one region and you tolerate some data loss. Are you aiming for the lowest cost, or do you want a standby node that takes over quickly on failure? If recovery taking hours is acceptable, backup+PITR alone is the most economical path; otherwise you need a warm standby.

  • Yes, recovery taking hours is acceptable (cheapest)
  • No, a warm standby that takes over within minutes is required

Recommendation: synchronous replica (zero data loss)

The primary does not complete a commit until at least one standby acknowledges it; so even if the primary is lost, no acknowledged transaction is lost (RPO=0). The ideal solution within one region on a low-latency network.

Recommendation: asynchronous standby (geographic DR)

The standby applies changes as a stream without delaying the primary's commits. It is the standard way to keep a copy in another region without hurting write performance; in exchange, a small data loss window (equal to the replication lag) is accepted.

Recommendation: automatic failover cluster

A cluster solution combining health monitoring, leader election and automatic takeover; it targets both low RTO (automatic failover within seconds) and low/zero RPO with a synchronous copy. Operational overhead is higher, but human intervention is minimized.

Recommendation: backup + PITR (most economical)

Instead of a running standby, only regular backups and point-in-time recovery (PITR) via WAL/archived logs are kept. It is the lowest-cost solution; the price is that recovery can take hours (high RTO).

Open in DBAtlas →