Patroni OSS for PostgreSQL HA

Patroni

Patroni is an open-source template that provides High Availability (HA) for PostgreSQL. It integrates with Distributed Configuration Stores (DCS) such as Etcd, Consul, ZooKeeper, and Kubernetes to automate leader election, automatic failover, and replication management of PostgreSQL clusters. This enables continuous service even when the master node fails.

Key Facts

NamePatroni
Repositorygithub.com/patroni/patroni
Stars8.8k (as of 2026-10)
Forks1.0k (as of 2026-10)
LicenseMIT
PurposePostgreSQL high availability / automatic failover
CategoryDatabase / HA / PostgreSQL

Architecture

Patroni Architecture

Key Features

Key features of Patroni include:

  • Automatic failover: Through leader election using a Distributed Configuration Store (DCS), a new leader is automatically promoted when the master node fails.
  • Replication management: Automates configuration and control of synchronous and asynchronous replication to maintain data consistency.
  • DCS integration: Supports multiple distributed coordination services, including Etcd, Consul, ZooKeeper, and Kubernetes.
  • REST API: Provides a REST API for retrieving cluster state and performing operations such as manual failover.
  • Kubernetes integration: Combined with StatefulSets or Operators, Patroni enables easy construction of PostgreSQL HA clusters on Kubernetes.

Patroni is often used together with connection poolers and load balancers such as HAProxy or PgBouncer to provide a transparent connection endpoint to clients. It is adopted in production environments by many companies including Zalando.

Patroni's GitHub repository can be found at the following URL: https://github.com/patroni/patroni

By using Patroni, high-availability operation of PostgreSQL clusters can be automated, minimizing downtime during failures. Operators are freed from manual failover work and complex replication management, enabling the construction of a reliable database foundation.

Use Cases for Patroni

Patroni is an open-source template that automates the high-availability operation of PostgreSQL clusters. Below, we explain in detail how Patroni is used in certain software architectures, why it is used in those software architectures.

Use Cases

For example, if a company operates a mission-critical web service or SaaS, database layer downtime directly leads to revenue loss and user churn. In such cases, when the PostgreSQL master node fails, it is necessary to automatically promote a standby node and continue service without waiting for manual intervention. Patroni is very useful for companies focused on achieving SLA/SLO as it can realize automatic failover in combination with distributed coordination services.

Use in Software Architectures

Patroni is an HA template based on PostgreSQL's standard replication features. A Patroni agent is placed on each PostgreSQL node, and the state of the entire cluster is shared and the leader is elected through a DCS such as Etcd/Consul/ZooKeeper. Therefore, it is suitable for a wide range of infrastructure configurations, including on-premises bare-metal environments, virtualized platforms, and StatefulSets on Kubernetes.

Purpose of Use

Companies that operate mission-critical systems must minimize database layer downtime. By using Patroni, master failures can be automatically detected and a standby can be promoted within seconds to tens of seconds. This maintains service availability while significantly reducing the manual operation burden on operators.

The Patroni source code includes the following key components:

  1. Patroni Agent:

    • This component contains the code of the agent process running on each PostgreSQL node. It handles PostgreSQL process management, health checks, participation in leader election, and configuration application.
  2. DCS Adapter:

    • This component contains the code of the adapter layer that abstracts connection and operation to multiple distributed coordination services such as Etcd, Consul, ZooKeeper, Kubernetes, and Exhibitor. Switching DCS according to the environment can be done easily.
  3. REST API:

    • This component contains the code of the REST API server for externally operating cluster state retrieval, manual failover, and configuration changes. It is also used as a health check endpoint for HAProxy.
  4. Bootstrap / Replication:

    • This component contains the code that automates the initialization of new clusters, base backup acquisition for standby nodes, and streaming replication configuration. Integration with pg_basebackup, WAL-G, and pgBackRest is also supported.
  5. Watchdog:

    • This component contains the code for watchdog integration for fencing purposes. To avoid split-brain scenarios, it provides a mechanism to forcibly restart the node when the leader is lost.

These components share responsibilities to realize the key functionalities of the Patroni project. Each component is loosely coupled, enabling flexible configurations according to the environment. The Patroni source code is available at https://github.com/patroni/patroni, so those interested can check for more details.