Ask whether the database is resilient and the team may answer, “We have a replica.” A business leader may hear that operations will continue during an outage. An engineer may mean that reports run on another server. They are describing the same infrastructure but promising different outcomes.
Replication propagates changes between copies of data. This article uses a common primary-and-replica arrangement: one node accepts writes and others receive changes. Multi-writer systems exist, but their conflict handling is a separate subject. Even this simpler arrangement needs three distinct decisions: offloading reads, recovering from server failure and recovering from an incorrect change.
A reporting replica is not automatically a standby
A read replica can move suitable queries away from the primary. For example, an expensive internal report may interfere with operational work. If slightly delayed data is acceptable, it can run elsewhere.
The replica must still apply the primary's updates. When resources are insufficient, it falls behind. Adding replicas does not automatically raise the primary's write throughput or eliminate the need to improve expensive queries.
A failover target has different requirements: sufficiently current data, capacity to take the operational workload, appropriate configuration and a working connection path from applications. A replica already saturated by reporting may not qualify. This is something to demonstrate, not infer from its name.
An acknowledged write may be missing from the standby
With asynchronous replication, the primary can acknowledge a change before it reaches another node. If the primary is irretrievably lost, the promoted replica may lack a transaction already reported as successful. The PostgreSQL replication documentation describes that failure window.
The business question is more uncomfortable than “what is our lag?” Are we prepared to lose a change after telling the user it was saved? If not, the acknowledgement policy and its failure assumptions must support that requirement. A second machine alone promises nothing.
Synchronous replication can make commits wait for selected standby acknowledgements. That changes write latency and dependence on those nodes being available. The meaning of an acknowledgement also matters: received, persisted durably or applied so readers can see it are different guarantees. “Synchronous” without the configuration does not mean every replica immediately returns the latest state.
Discuss recovery time and data loss separately. RTO describes the recovery-time objective; RPO describes the recovery-point objective, commonly expressed as a tolerable loss window. Quickly promoting a stale copy and preserving every acknowledged write are not interchangeable requirements. Different operations may justify different designs.
A user expects to read back their own change
An employee corrects a customer's details. The write reaches the primary, but the next screen reads an old value from a replica. The employee assumes Save failed and repeats the action. The infrastructure is following its configuration; the product is communicating the wrong thing.
Design those read paths explicitly. Following a write, the application might read from the primary or wait for a particular replica to apply that change. A report may instead display when its data was current. The choice belongs to the operation, not just the desire to spread requests evenly.
Reading the primary does not fix incorrect concurrency rules either. Replication and transaction isolation solve different problems. A responsive screen also does not replace authoritative checks before consequential business actions.
Monitoring should distinguish changes a replica has not received from changes it has received but not applied. These call for different responses. A green connection indicator establishes neither freshness nor readiness. Capacity, resource headroom and storage health matter as well. Two servers sharing power, networking or another dependency do not protect against failure of that shared component; describe the actual outage the design is intended to survive.
Failover needs its own procedure
Losing connectivity is not proof that the primary has stopped. During a network partition it may remain active. Allowing another node to accept writes at the same time can create conflicting histories. Failover therefore needs protection against two active primaries.
The system must also choose a suitable candidate, redirect applications, restore connections and resolve requests whose outcome is unknown. A timeout during an outage does not prove the write never occurred. Important retries need appropriate idempotency safeguards.
The PostgreSQL failover guidance explicitly discusses the old primary returning. A managed provider may automate some steps, but applications must still handle interrupted connections and a changed writer.
A replica repeats an accidental deletion too
If a faulty application deletes valid records, an ordinary up-to-date replica applies that deletion. It is just another change. Replication therefore does not replace independent backups and point-in-time recovery.
Backup retention, access controls and restoration tests are separate decisions. Credentials able to delete both production data and every backup leave a dangerous shared dependency. PostgreSQL's continuous archiving documentation explains recovery using a base backup and archived changes.
For acceptance, request a controlled failover test and a separate accidental-deletion recovery test rather than counting database nodes. Include the application: did useful work resume, which acknowledged operations survived, and how much manual intervention was required?
Record the conditions of that test. A lightly loaded exercise does not establish performance during the busiest part of the day. Note which intervention was automatic, what required an operator and whether the available team can repeat that process outside working hours.
After a successful switch, the former replica is serving production. Unless another standby is ready, redundancy has been lost. The incident plan should name who restores that protection, not end at the moment users can work again.