Free audit

View Audit Scope

Strategic advisory — not execution

Patroni Consulting Services

In short: Patroni is an open-source template for building highly available PostgreSQL clusters, using a distributed configuration store (etcd, Consul, ZooKeeper, or the Kubernetes API) to manage leader election and automatic failover. Patroni consulting covers DCS selection, failover and watchdog tuning, callback hooks, and multi-region HA topology design.

DCS selection (etcd / Consul / ZooKeeper / K8s API), failover tuning, watchdog configuration, multi-region HA topology, Patroni vs pg_auto_failover decision, and callback hook design. See the Patroni hub for the broader services overview.

Sound familiar?

  • ▸ DCS selection is blocking the Postgres HA design — etcd vs Consul vs K8s API choice depends on the rest of your infrastructure and the team hasn't reached consensus.
  • ▸ Failover false-positives are causing churn — tuning is needed to balance fast RTO against stability under transient network issues.
  • ▸ Multi-region HA requirement just landed — Patroni's active-passive cross-region story needs design before commitment.

JusDB Patroni consultants give you the written DCS + failover-tuning design. Book a Patroni architecture review →

What our Patroni consulting covers

Each deliverable is a written architecture document, DCS + failover-tuning design, or topology proposal with rationale.

01

DCS Selection

etcd / Consul / ZooKeeper / K8s API decision based on existing infrastructure, operational complexity, and team expertise.

02

Failover Tuning

ttl / loop_wait / retry_timeout balanced against RTO targets and network reliability — avoiding both slow failover and false-positive churn.

03

Watchdog Configuration

Softdog kernel-module setup, watchdog-ttl vs DCS-ttl alignment, fence-on-failover guarantees to prevent split-brain scenarios.

04

Multi-Region HA

Active-passive cross-region topology, sync-within-region + async-across-region, DR promotion runbooks, RPO/RTO budget design.

05

Patroni vs pg_auto_failover

Decision matrix — Patroni’s flexibility vs pg_auto_failover’s simpler operational model with Postgres-as-coordination.

06

Callback Hooks Design

on_role_change / on_restart hooks for app-tier reconnect, HAProxy backend updates, monitoring integration — conservative error handling.

Patroni consulting — common questions

What does Patroni consulting cover?
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.
Which DCS should I pick — etcd, Consul, ZooKeeper, or K8s API?
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.
Watchdog configuration — when is it needed?
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.
Patroni vs pg_auto_failover — which fits?
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.
Callback hooks — what do I use them for?
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.
Multi-region Postgres HA with Patroni — how to design?
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.
Failover tuning — how to balance speed vs stability?
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.

Ready to design your Patroni topology?

Book a 30-minute scoping call. We'll review your topology, surface optimisation opportunities, and propose the right engagement shape.