A PostgreSQL replica can hold another copy of data, but a database service also needs to decide which member should accept writes after a failure. Patroni coordinates PostgreSQL high availability, including leader selection and controlled role changes, using a shared configuration store such as Kubernetes. It gives database operators building blocks for managing that behavior. It does not remove the need to choose replication settings, maintain backups or make sure clients reconnect safely when the primary changes.
Current guidance
The recovered chart deployed Patroni through Spilo and a StatefulSet. Patroni remains a PostgreSQL high-availability framework: its Kubernetes integration can store leader and configuration state in Kubernetes objects without a separate etcd deployment. The documentation distinguishes Endpoints and ConfigMap modes, so preserving election state and service selection is essential when changing packaging.
Choose direct Patroni only if the team owns database lifecycle tasks around it. An operator based on Patroni can additionally manage declarative cluster creation, but its CRDs and recovery procedures are a separate contract. Replica count alone does not establish a recovery-point objective: assess replication mode, failure domains, fencing and what clients do during a primary change.
Before migration, record cluster identity, PostgreSQL major version, replication slots, users, extensions, role labels and service selectors. Test a controlled switchover and restore from backup in isolation. Do not let an old and new controller manage the same database simultaneously. The upstream warns that its basic Kubernetes examples are not a complete persistent-volume deployment; use the documented production packaging deliberately.
Historical upstream link check · 2026-10-09
The recorded upstream address redirects to https://github.com/patroni/patroni and returned HTTP 200 on 2026-10-09. GitHub does not mark patroni/patroni archived or disabled; this does not establish active maintenance, support or compatibility. GitHub resolves the old repository identity to patroni/patroni. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
A template for HA PostgreSQL on Kubernetes.
This chart contains a Kubernetes chart to deploy a five node Patroni cluster using a Spilo and a StatefulSet.
Patroni is a template for you to create your own customized, high-availability solution using Python and – for maximum accessibility – a distributed configuration store like ZooKeeper, etcd, Consul or Kubernetes. Database engineers, DBAs, DevOps engineers, and SREs who are looking to quickly deploy HA PostgreSQL in the datacenter-or anywhere else-will hopefully find it useful.
We call Patroni a “template” because it is far from being a one-size-fits-all or plug-and-play replication system. It will have its own caveats. Use wisely.
Note to Kubernetes users: Patroni can run natively on top of Kubernetes. Take a look at the Kubernetes chapter of the Patroni documentation.
Patroni originated as a fork of Governor, the project from Compose. It includes plenty of new features. Patroni is in active development and accepts contributions. There are two places to connect with the Patroni community: on github, via Issues and PRs, and on channel #patroni in the PostgreSQL Slack.
Replication Choices
Patroni uses Postgres’ streaming replication, which is asynchronous by default. Patroni’s asynchronous replication configuration allows for maximum_lag_on_failover settings. This setting ensures failover will not occur if a follower is more than a certain number of bytes behind the leader. This setting should be increased or decreased based on business requirements. It’s also possible to use synchronous replication for better durability guarantees.
Applications Should Not Use Superusers
When connecting from an application, always use a non-superuser. Patroni requires access to the database to function properly. By using a superuser from an application, you can potentially use the entire connection pool, including the connections reserved for superusers, with the superuser_reserved_connections setting. If Patroni cannot access the Primary because the connection pool is full, the behavior will be undesirable.
Sources & further reading
Spotted something that needs another look?
Help improve this page →