Question 1

What does Patroni consulting cover?

Accepted Answer

DCS (Distributed Configuration Store) selection - etcd vs Consul vs ZooKeeper vs Kubernetes API, failover sequence tuning (ttl, loop_wait, retry_timeout), watchdog configuration for fence-on-failover, callback hooks for app-tier failover coordination, multi-region HA topology, Patroni vs pg_auto_failover decision, monitoring + alerting design (Patroni REST API, Prometheus integration). Deliverables are written architecture documents.

Question 2

Which DCS should I pick - etcd, Consul, ZooKeeper, or K8s API?

Accepted Answer

etcd: lightweight, fast, smaller operational surface - best for dedicated Postgres HA without other stack overlap. Consul: when you already run Consul for service discovery elsewhere, integration is natural. ZooKeeper: when other stack uses ZK (Kafka, Solr, older Hadoop) - but adds JVM operational burden. K8s API: when Postgres is K8s-native (Zalando/CrunchyData/Stackgres operators use this) - DCS is the K8s API itself, no extra cluster. We pick based on your existing infrastructure, not on what's 'best' in isolation.

Question 3

Watchdog configuration - when is it needed?

Accepted Answer

Watchdog ensures Patroni terminates the Postgres process if Patroni itself becomes unresponsive (avoiding split-brain scenarios where two nodes think they're primary). Required for production HA - without it, network partition + Patroni hang creates dual-primary risk. Configuration: softdog kernel module enabled, watchdog timeout less than DCS ttl. We design the watchdog parameters around your failover-RTO targets and the DCS reliability profile.

Question 4

Patroni vs pg_auto_failover - which fits?

Accepted Answer

Patroni: mature, configurable, supports more DCS backends, larger community + ecosystem. pg_auto_failover (CitusData/Microsoft): simpler operational model - uses a Postgres database itself as the coordination layer (no separate DCS needed), elegant primary-secondary-witness 3-node topology. For most production deployments, Patroni's flexibility wins. For teams that want to avoid running etcd/Consul/ZK and prefer Postgres-as-coordination, pg_auto_failover is the cleaner answer.

Question 5

Callback hooks - what do I use them for?

Accepted Answer

Patroni emits events at lifecycle transitions (on_start, on_stop, on_role_change, on_restart, on_reload). Common use cases: trigger application-tier reconnect on role change, update HAProxy backend state on failover, notify monitoring systems of leader election, run pg_repack or analytics jobs only on replicas. We design hook scripts conservatively - failures in callbacks can interrupt failover sequences if not handled correctly.

Question 6

Multi-region Postgres HA with Patroni - how to design?

Accepted Answer

Patroni supports synchronous replication within a region + asynchronous cross-region replicas. For multi-region active-active writes (writes accepted in multiple regions), Patroni isn't the right tool - that's CockroachDB/YugabyteDB territory. For multi-region active-passive (writes in primary region, async replicas in DR regions with manual promotion on full-region failure), Patroni works well. We design the cross-region topology, RPO/RTO budgets, and promotion runbook for DR scenarios.

Question 7

Failover tuning - how to balance speed vs stability?

Accepted Answer

Aggressive tuning (short ttl, short loop_wait) gives faster failover but more false-positive failovers on transient issues. Conservative tuning (longer ttl, longer loop_wait) gives stable behaviour but slower RTO. Typical balance: ttl=30, loop_wait=10, retry_timeout=10 - gives ~30-45 second failover with reasonable false-positive resistance. We tune around your specific network reliability profile and RTO requirements.

Patroni Consulting Services

What our Patroni consulting covers

Patroni consulting - common questions

Ready to design your Patroni topology?