Topic
Replication, point-in-time recovery, promotion, connection limits, and the version-upgrade surprises that only ever show up under production traffic.
PostgreSQL is the database I have used longest — since 2017 — and still my default for transactional systems. Most of what I know about it comes from the operational side rather than the query side: how far behind a standby actually falls under write pressure, point-in-time recovery you have rehearsed instead of documented, promotion while traffic is still arriving, connection limits meeting an application that opens a pool per worker, and major-version upgrades. On my failover rig, PostgreSQL 18 streaming replication held a replay lag of 383 µs — measured on the rig, not quoted from a release note.
Wire pgBackRest into a running Patroni cluster over mutual TLS with Ansible, then prove it: full backup, replica rebuilt from the repo, and a point-in-time restore.
~90 min on an existing cluster; the restore drill itself is ~15 min
Build a two-node Patroni cluster on Rocky 8 under QEMU, then SIGKILL the leader and measure the promotion, the timeline bump, and the pg_rewind rejoin.
~2–3 h first bring-up (TCG is slow); ~5 min for the failover itself
Stand up a dedicated pgBackRest TLS repo host on generic/rhel8 with Ansible-issued certs, then prove server-ping and mTLS from a client VM.
~90 min first bring-up (TCG + dnf)
Apple Silicon labs that boot still fail host and mesh ping when you use aarch64 boxes or park the VMs on your Wi‑Fi subnet.
~60–90 min first bring-up (TCG is slow)
The mount point moved in the PG 18 image, so every compose file copied from a 12–17 guide breaks. The corrected file, then replication, promotion and PITR.
~35 min hands-on
Six database engines, eight failover scenarios, one 8-CPU Docker rig. The results matrix, the headline measurements, and how to run the first scenario.
~45 min hands-on