TwinhullPostgreSQL high availability
you can prove works.
Tutorials get you a cluster that starts. This kit gets you one that survives: tested Patroni configs, a failover drill that measures your real downtime and data loss, health checks, backups, runbooks, and a lab to rehearse it all.
Pull the plug on your leader. Get a report.
failover-drill writes to your cluster every 200 ms, takes the leader away (planned switchover, clean stop, or a hard crash), then checks every committed row and times every second of downtime.
You get a report you can hand to your manager or your auditor: how long writes stopped, how many transactions were lost, and whether the old leader rejoined by itself.
$ sudo bin/failover-drill --mode crash ▸ preflight: ha-check Overall: OK ▸ leader is pg1 (timeline 1); mode: crash ▸ writer running (12 commits so far) ▸ CRASHING pg1 (SIGKILL Patroni + PostgreSQL) ▸ waiting for a new leader... ▸ new leader: pg3 ▸ restarting pg1 — it must rejoin as a replica | Write downtime | 24.2 s | | Committed transactions lost | 0 | | Old leader back as replica | 33.8 s | Verdict: PASS Report: reports/drill-…-crash.md
The first real failover shouldn't be the test.
Blog configs aren't tested
Most Patroni guides stop once patronictl list shows three green members. Nobody kills the leader, restores a backup, or checks that the old primary comes back.
The bugs hide until 3 a.m.
A stray environment variable can silently break pg_rewind. Everything looks healthy for months, until the first unplanned failover leaves you one replica short.
Auditors want evidence
Banks, payment and healthcare teams have to show that failover and restore are tested. "It worked in the tutorial" is not evidence. A dated drill report is.
Every release is tested on a real 3-node cluster
v1.0 test run: PostgreSQL 16, Patroni 4.1.5, etcd 3.6.15, HAProxy 2.8, default timings (ttl 30 s). Ranges cover repeated runs.
| Scenario | Write downtime | Committed transactions lost | Old leader rejoins |
|---|---|---|---|
| Planned switchover | 4.7–5.0 s | 0 | ~10 s |
| Clean stop of the leader | 4.7–7.0 s | 0 | ~14 s |
| Hard crash of the leader (kill -9), async | 24–30 s | 0 | ~34 s |
| Hard crash, synchronous replication | 23.2 s | 0 | 31 s |
| Hard crash, etcd with mutual TLS | 26.4 s | 0 | 34 s |
| 2 of 3 etcd members down | 0 s — primary kept writing | 0 | — |
Point-in-time restore after DROP TABLE | planned outage | 0 rows before the target | replicas rebuilt |
A crash takes about ttl seconds because a dead leader can't release its lock. The guide explains how to tune it, and what faster settings cost you. Your numbers depend on your network: the drill measures yours.
Tools, templates, a lab and a 10-chapter guide
One file, every config
Describe the cluster once in cluster.env. Every Patroni, etcd, HAProxy, keepalived and pgBackRest file for every node is generated and validated. It refuses weak secrets, unsafe timings and two-node clusters.
Servers checked before install
Clock sync, kernel settings, versions, disks, ports, watchdog, and the environment variables that break Patroni. Run it on each node before you start.
Health in one command
etcd quorum, leader, replication lag, routing, WAL archiving, backup age and replication slots. Nagios/Zabbix exit codes and JSON output for Prometheus.
Proof, with numbers
Switchover, clean stop or crash, with measured downtime, lost transactions and rejoin time. The report is ready for an audit.
Backups that survive failover
The same cron job on every node, and only the current primary backs up. The point-in-time restore procedure is tested step by step.
A 3-node cluster on one VM
Rehearse failovers, restores and upgrades before production. It uses the same templates and scripts, and runs in under a minute.
Written for the day something goes wrong
Every chapter leads with the decision or the command, then explains why. The disaster-recovery runbook is written for an on-call engineer with no time to read.
Read chapter 10 excerpt free- Architecture and every design decision explained
- Server preparation, sizing, ports, packages
- Installation, step by step, with expected output
- Operations: switchover, parameters, upgrades, adding nodes
- Backups and a tested point-in-time restore
- Monitoring: Nagios, Zabbix, Prometheus
- Failure drills and how to read the report
- Disaster-recovery runbook: 8 scenarios
- Security: etcd mutual TLS, REST API, secrets
- Troubleshooting: real failures and their fixes
Four production traps the tutorials miss
Each one broke our test cluster before release. Each one is fixed in the kit, and explained in free articles.
A password variable that breaks pg_rewind
PGPASSWORD in Patroni's environment overrides its .pgpass. Planned switchovers still work, but after a crash the old leader can't rejoin the cluster.
Ubuntu's etcd doesn't work with Patroni
Ubuntu 24.04 ships etcd 3.4. Patroni loops forever on a cryptic AttributeError and never starts.
Patroni reads your deploy script's variables
Any PATRONI_* environment variable overrides patroni.yml, so a harmless-looking variable name in a deploy script changes the cluster's behaviour.
Archiving fails from the first second
WAL archiving starts at bootstrap, before any backup stanza exists. Unless you know the order, pg_wal quietly fills up.
Built for
- DBAs and DevOps engineers running PostgreSQL on their own VMs or servers
- Teams in regulated industries who need tested continuity: banking, payments, healthcare, government
- Anyone replacing a single PostgreSQL server with a 3-node cluster
- Teams whose Patroni cluster exists but has never been failure-tested
Not for
- Kubernetes. Use an operator such as CloudNativePG, Zalando or Crunchy.
- Managed databases (RDS, Cloud SQL, Azure). The provider handles failover.
- Complete beginners. You should be comfortable with Linux and basic PostgreSQL administration.
We'd rather tell you now than refund you later.
One payment. Yours to keep.
Less than one hour of a consultant's time. The same material as a 3-day training course, plus the tools.
Solo
One engineer · one-time payment
- The complete kit: tools, templates, lab
- The 10-chapter guide and DR runbook
- Use it on every cluster your organisation runs
- 12 months of updates
Team
Up to 10 engineers at one company · one-time payment
- Everything in Solo, for the whole team
- Priority email support for 12 months
- Invoice with your company details
- 12 months of updates
30-day refund, no questions asked. Prices in USD; sales tax or VAT is added at checkout where it applies. Payments are handled by our reseller, Paddle.com, which issues your invoice.
Questions
Which versions does it support?
Patroni 4.x, etcd 3.5 and newer, HAProxy 2.x, pgBackRest 2.x, and PostgreSQL 14 to 18 on Ubuntu 22.04/24.04, Debian 12 and RHEL-family 8/9. Every release note lists exactly what was re-tested. v1.0 was tested on PostgreSQL 16 and Ubuntu 24.04.
Can I see the quality before buying?
Yes. Read the free chapter excerpt and the articles. And there's the 30-day refund.
Can I use it on production clusters at work?
Yes. The license covers every cluster your organisation owns or operates. Solo covers one engineer; Team covers up to ten. You may modify the files for internal use. You may not redistribute or resell them.
Does it work in the cloud?
On virtual machines, yes (AWS EC2, Azure VMs, GCP, Hetzner, on-premises VMware and others). Cloud networks often block VRRP; the guide covers the alternatives to a floating IP, such as a cloud load balancer or multi-host connection strings.
What if a script damages my cluster?
The scripts refuse unsafe actions by default: crash drills in production need an explicit --yes. Rehearse everything in the lab first. The kit comes without warranty, as described in the license.
How do I get updates?
By email, with a new download link, for 12 months. After that you keep your version forever.
Is Twinhull affiliated with PostgreSQL or Patroni?
No. Twinhull is an independent publisher. PostgreSQL, Patroni, etcd, HAProxy and pgBackRest are open-source projects with their own licenses; the kit configures them and does not include them.