⚡ Postgres Database Administration – EDB Failover Manager (EFM) vs. Patroni
20 questions · 15 min timer · Explanations included · Free
Two tools solving the same problem with different assumptions. EFM uses agents and a witness node to reach a failover decision. Patroni delegates that decision to a distributed consensus store — etcd, Consul, or ZooKeeper — and lets the DCS decide who holds the leader key.
That architectural split drives almost every practical difference: how each handles a network partition, what happens in Kubernetes, how they behave across regions, and where each one needs a human.
What this quiz covers
- Architecture — EFM’s agent-and-witness model against Patroni’s DCS-backed leader election
- Split-brain prevention — fencing in EFM, leader keys and TTL in Patroni, and why an isolated primary is more dangerous than a dead one
- Virtual IPs — the role of the VIP in EFM failover, and the failure mode when it isn’t configured
efm.properties— the settings that decide whether a slow network becomes an outage- Patroni with etcd — TTL tuning, and why a very low TTL causes failovers you didn’t want
- Cloud-native and Kubernetes — where Patroni tends to fit better, and multi-region considerations
- When humans are still required — the scenarios neither tool resolves alone
Common mistakes
- Running a two-node EFM cluster with no witness — there’s no quorum, so there’s no safe decision
- Setting Patroni’s TTL aggressively low and turning brief network noise into repeated failovers
- Assuming
efm cluster-statusreflects reality during a partition; it reflects what the agents can currently see
Twenty questions below, each with an explanation.
