We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Cold standby gives you the cheapest spare but the longest recovery. Hot standby gives you instant failover but at double the infrastructure cost. Warm standby sits between them: a running database that receives but serves no traffic, ready to promote in minutes rather than hours.
Most production Postgres and MySQL deployments run warm standbys. Amazon RDS Multi-AZ is a warm standby. Aurora read replicas that you have designated for failover promotion are warm standbys. Google Cloud high-availability instances are warm standbys. The pattern is so common that managed database services ship it as a checkbox, but the promotion mechanics underneath that checkbox are where real outages happen.
Robinhood went down for 17 hours in March 2020 because their warm standby promotion got stuck. The standby was receiving replication but had fallen behind on replay. When the primary failed, the orchestrator tried to promote a standby that was not actually caught up, and the resulting confusion cascaded into a full-day outage during one of the highest-volume trading days that year. The standby existed. The replication was running. The promotion still failed. Understanding why requires knowing what "warm" actually means at the implementation level.
A warm standby is a running database instance that continuously receives data changes from the primary but does not accept client connections for reads or writes.
| Property | Warm Standby |
|---|---|
| State | Running, applying stream |
| Serves traffic | No (or limited read-only on some configurations) |
| Replication mode | Async or sync, typically WAL shipping or streaming replication |
| Promotion time | 60 to 180 seconds for a healthy standby |
| Data lag behind primary | Seconds (async) to zero (sync) |
| Infrastructure cost | One full-size instance running idle |
| Best for | Single-region HA, regulated environments needing fast manual failover |
| Failure mode | Promotion gets stuck if replay queue is backlogged |
The distinction from hot standby is that warm does not serve any production traffic. A hot standby typically handles read queries, which means it is already warmed up and running at production load. A warm standby is idle, which makes it cheaper to reason about but introduces a cold-start risk at promotion time because the buffer pool may not contain the working set.
The distinction from cold standby is that warm keeps the replication stream alive. A cold standby is a powered-off server with a copy of the data sitting on disk. Activating a cold standby means starting the instance, restoring the last backup, replaying all WAL since the backup, and then warming up. That process takes 30 to 60 minutes minimum. A warm standby skips all of that because it has been applying changes continuously.