Don't Do High Availability, Do Right Availability
summary
Argues that full high availability often adds cost and complexity and instead matches design to the SLA: examples include replacing a three-node cluster with a single VM for a ticketing app, running a simple file-transfer service on one small VM, and avoiding Kubernetes multi-node pain. Recommends concrete controls: use PG Bouncer, archive WAL streaming with synchronous_commit=remote_apply or remote for zero or minute-level data loss, back up with Barman or pgbackrest, monitor backups and practice recovery. Claims many services accept a 98% SLA or a day of loss.
AI-written summary · about
chapters (6)
- 0:00Introduction and philosophy
- 2:44The cost of complexity
- 3:36Defining your requirements
- 4:31Technical strategies and tools
- 35:19Closing thoughts
- 35:33Questions and answers
related talks
36mDesigning Layered High‑Availability Architectures for PostgreSQL on a Budget
46mDeploying Maximum HA Architecture With Postgres
45mChasing unicorns : 0 dataloss and 99.999% availability
47mPostgreSQL High Availability: The Considerations and the Candidates
20mFlying High with Highly Available SQL Server Deployments
58mDatabase High Availability
52mOverview of Solutions for PostgreSQL High Availability
55mHigh Availability with PostgreSQL and Pacemaker