Patroni & etcd/Consul
Patroni 3.x automates PostgreSQL leader election, failover, and configuration management. It stores cluster state in a distributed config store (DCS): etcd or Consul.
Search across all documentation pages
Patroni 3.x automates PostgreSQL leader election, failover, and configuration management. It stores cluster state in a distributed config store (DCS): etcd or Consul.
Three-node Patroni cluster with etcd quorum and PostgreSQL 18.4.
# /etc/patroni/patroni.yml (snippet)
scope: prod-pg18
namespace: /service/
name: pg1
restapi:
listen: 0.0.0.0:8008
connect_address: 10.0.1.11:8008
etcd3:
hosts: 10.0.2.1:2379,10.0.2.2:2379,10.0.2.3:2379
bootstrap:
dcs:
ttl: 30
loop_wait: 10
retry_timeout: 10
maximum_lag_on_failover: 1048576
initdb:
- encoding: UTF8
- data-checksums
postgresql:
listen: 0.0.0.0:5432
connect_address: 10.0.1.11:5432
data_dir: /var/lib/postgresql/18/main
authentication:
replication:
username: replicator
password: repl-secret
superuser:
username: postgres
password: postgres-secret# Start Patroni on each node
sudo systemctl enable --now patroni
# Cluster status
patronictl -c /etc/patroni/patroni.yml listWhen to reach for this: Self-hosted PostgreSQL HA with automated failover and API-driven health checks.
Deploy etcd, bootstrap Patroni, verify failover candidate:
# etcd 3-node cluster health
etcdctl endpoint health --endpoints=https://10.0.2.1:2379,https://10.0.2.2:2379,https://10.0.2.3:2379
# Patroni cluster view
patronictl -c /etc/patroni/patroni.yml list-- On any member via Patroni-managed endpoint
SELECT pg_is_in_recovery();# Controlled switchover (not emergency failover)
patronictl -c /etc/patroni/patroni.yml switchover --master pg1 --candidate pg2 --forceWhat this demonstrates:
/service/prod-pg18/leader).postgresql.conf, recovery config, and promotion.patronictl switchover exercises planned leader change with lag guard (maximum_lag_on_failover).| Store | Pros | Cons |
|---|---|---|
| etcd 3.x | Kubernetes-native, mature Patroni path | Operate 3+ nodes for quorum |
| Consul | Multi-datacenter, service mesh integration | Patroni consul config differs from etcd |
| Kubernetes | CRD / endpoints as DCS | Requires K8s operator patterns |
primary_conninfo updates)| Setting | Purpose |
|---|---|
ttl | Leader lease duration |
loop_wait | Patroni polling interval |
maximum_lag_on_failover | Block promotion if replica too far behind |
synchronous_mode | Enable sync quorum management |
maximum_lag_on_failover too high - Promote stale replica, large RPO. Fix: Set based on measured byte lag SLA.patronictl list after ACL changes.pg_ctl promote bypassing Patroni - Cluster state desync. Fix: Always use patronictl failover or switchover.| Alternative | Use When | Don't Use When |
|---|---|---|
| repmgr | Legacy repmgr expertise | Greenfield (Patroni is de facto standard) |
| Manual failover runbook | Tiny dev clusters | Production tier-0 |
| Cloud managed HA | RDS Multi-AZ | Custom extensions + Patroni hooks |
Both work. etcd is more common in Kubernetes-heavy shops; Consul fits existing HashiCorp stacks.
Minimum 3 for meaningful HA: 1 leader + 2 replicas (one sync candidate optional).
Patroni does not run PgBouncer; use callbacks or HAProxy checks to repoint pools after failover.
Supported. Match Patroni release notes for PG 18 binaries and data_dir paths.
Disables automatic failover during maintenance. Resume promptly; document who paused.
Stack versions: This page was written for PostgreSQL 18.4 (stable 18, maintenance 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, and PostGIS 3.5+.
Reviewed by Chris St. John·Last updated Jul 19, 2026