When working with customers, a common question we get is: “Which standby type is best for our HA needs?” Before answering, we ensure they fully understand the concepts behind each standby type and provide the necessary guidance
A standby server is essentially a copy of your primary database that can take over if the primary fails.
There are different types of standby setups, each with its own use cases, pros, and cons. In this blog, we will discuss the three types: Cold Standby, Warm Standby, and Hot Standby.
1. Standby Types
1.1. Cold Standby
A cold standby is simply a backup server that is powered off or not running PostgreSQL until the primary server fails. It usually relies on periodic backups or filesystem snapshots.
When the primary fails, you manually bring up the standby by restoring backups or activating the server.
1.2. Warm Standby
A warm standby is a standby server that continuously receives WAL (Write-Ahead Log) files from the primary database, but it does not serve application queries. It remains in recovery mode, applying the incoming WAL files to stay updated.
If the primary server fails, the warm standby can be promoted to the new primary through manual failover.
1.3. Hot Standby
A hot standby is an active standby server that streams WAL data from the primary in near real time. While applying changes, it also supports read-only queries, making it useful for offloading reporting or analytics workloads.
In the event of a failure, the standby can be quickly promoted to the primary through automated failover.
2. Pros, Cons, and Use Cases of Each Standby Type
| Standby Type | Pros | Cons | When to Use |
| Cold Standby | Simple to set up Very low cost No replication overhead on primary |
Slow/Manual recovery High risk of data loss Requires manual intervention |
low-budget env Non-critical systems Test or development environments |
| Warm Standby | Faster recovery than cold standby RPO can be near or at zero RTO can be minimized with proper monitoring. |
More costly than a Cold standby Not usable for read queries until promoted Failover is usually manual |
DR setups for regional failover When moderate downtime is acceptable Environments without read scalability needs |
| Hot Standby | Failover is automatically handled Easier PostgreSQL upgrades with hot standby, requiring minimal downtime. Supports read-only queries |
Require a dedicated tool to configure Long read queries can delay WAL replay and cause replication lag. With only one primary–standby pair, there’s a risk of split-brain. |
Mission-critical production systems High-traffic applications needing read scalability Environments requiring minimal downtime & data loss |
3. Conclusion
Choosing the right standby type really depends on your business needs:
- Cold Standby → Low cost, high downtime, higher data loss → suitable for non-critical systems.
- Warm Standby → Medium cost, moderate recovery, limited usage → suitable for disaster recovery.
- Hot Standby → Higher cost, minimal downtime, scalable reads → best for mission-critical production systems.