Umair Shahid explains that it’s like an onion:
High availability for PostgreSQL is often treated as a single, big, dramatic decision: “Are we doing HA or not?”
That framing pushes teams into two extremes:
- a “hero architecture” that costs a lot and still feels tense to operate, or
- a minimalistic architecture that everyone hopes will just keep running.
A calmer way to design this is to treat HA and DR as layers. You start with a baseline, then add specific capabilities only when your RPO/RTO and budget justify them.
My thing I would point out is that the first few layers are actually disaster recovery, and that high availability first comes into the picture with Layer 3. But if you think of it in terms of Business Continuity (High Availability + Disaster Recovery), then the approach is a good one.