1.3 역사와 생태계
Patroni의 출발점은 Zalando가 아니라 Compose다. 2015년 3월 Compose가 Governor라는 PostgreSQL 자동 failover 프로젝트의 첫 commit을 올렸고, 같은 해 7월 Zalando가 이를 fork해 Patroni라는 이름을 붙였다. 2016년 2월 Zalando 기술 블로그를 통해 공개적으로 소개됐다. 원조였던 Governor는 2016년 3월을 끝으로 실질적인 개발이 멈췄고 저장소는 archive됐는데, 그 README에는 Governor가 Patroni 프로젝트의 씨앗이 되었으며 Compose 자신도 Patroni를 자사 HA 솔루션으로 채택했다고 적혀 있다.
이후 9년 가까이 Zalando 저장소에서 개발되다가 2024년 6월 독립 org(github.com/patroni/patroni)로 이동했다. 한 회사 소속이던 프로젝트가 커뮤니티 프로젝트로 자리를 옮긴 것이다. 2026년 7월 기준 GitHub star는 약 8.6k이고, 커뮤니티 채널은 GitHub issues/discussions와 PostgreSQL Slack의 #patroni 채널이다.
버전 마일스톤
1.0은 2016년 7월에 나왔다. 이후의 굵직한 마일스톤은 다음과 같다.
| 버전 | 릴리스 | 대표 변경 |
|---|---|---|
| 2.0 | 2020-09 | etcd v3 프로토콜 지원(gRPC-gateway 경유), multiple synchronous standbys, 외부 DCS 없는 pure Raft(beta) |
| 2.1 | 2021-07 | failover/switchover를 견디는 logical replication slot(PostgreSQL 11+), REST API allowlist |
| 3.0 | 2023-01 | Citus 통합, DCS failsafe mode(failsafe_mode, 기본 false), Python 2.7 지원 마지막 |
| 3.1 | 2023-08 | Kubernetes role label 구성(kubernetes.leader_label_value 등), --validate-config 개선 |
| 3.2 | 2023-10 | tags.failover_priority(leader race 우선순위), patroni --generate-config |
| 3.3 | 2024-04 | patroni_barman contrib(Barman 연동 custom bootstrap/replica method) |
| 4.0 | 2024-08 | quorum 기반 synchronous replication, master에서 primary로 개명, member_slots_ttl, PostgreSQL 17 대응 |
| 4.1 | 2025-09 | patronictl demote-cluster, sync_priority tag, systemd notify unit, REST API에 receive/replay LSN과 lag 정보 |
흐름을 요약하면 2.x에서 DCS와 replication의 기반을 넓혔고, 3.x에서 Citus와 운영 편의(failsafe mode, 우선순위 tag, 설정 생성)를 더했으며, 4.x에서 quorum 기반 failover와 용어 정리라는 큰 손질이 있었다. 이 노트의 기준인 4.1.4는 2026년 7월 7일 릴리스로, 같은 날 유지보수 브랜치의 4.0.10과 3.3.11도 함께 나왔다.
4.0 breaking changes
4.0의 가장 큰 변화는 master라는 용어를 primary로 전면 개명한 것이다. 코드와 API 표면 전체에 걸친 변경이라 업그레이드 시 확인할 지점이 많다.
- Kubernetes role label 기본값이
master에서primary로 바뀌었다. 구값이 필요하면kubernetes.leader_label_value로 구성한다 - DCS에 기록되는 role 값과 REST API가 반환하는 role이
primary가 됐고,/switchover,/failover,/restart요청에서role=master를 더 이상 받지 않는다 /metrics에서patroni_mastermetric이 제거됐고, callback script는role=primary를 받는다patronictl의--master옵션이 제거됐다(--leader또는--primary사용). custom replica creation의no_master옵션은no_leader로 바뀌었다- 3.2부터 deprecated였던
bootstrap.users(사용자 생성 기능)가 제거됐다
raft가 남아 있다.대안 도구들
같은 문제를 푸는 도구가 Patroni만 있는 것은 아니다. 검증 가능한 사실 위주로 현재 상태를 짚어 본다.
repmgr는 EDB가 개발하고 유지하는 도구 스위트로, PostgreSQL 서버 클러스터의 replication과 failover 관리를 표방한다. 현재 버전 5.5.0이 PostgreSQL 12에서 18까지 지원하며, 라이선스는 GPL v3다.
pg_auto_failover는 자동 failover를 위한 PostgreSQL extension이자 서비스다. 상태 기계를 관리하는 monitor 노드를 별도로 두고, 각 PostgreSQL 노드에서는 pg_autoctl keeper가 돈다. 합의를 분산 저장소에 두는 Patroni와 달리 판단 주체가 monitor라는 단일 구성요소에 모여 있는 구조다. Microsoft가 저작권을 갖고 PostgreSQL License로 배포되며, 최신 릴리스 v2.2(2025-04)에서 PostgreSQL 17 지원이 추가되고 11과 12가 제외됐다.
Stolon은 Sorintlab의 cloud native PostgreSQL manager로, keeper, sentinel, proxy 세 컴포넌트로 구성되고 저장소로 etcd, Consul, Kubernetes API를 쓴다. 설계만 보면 Patroni와 가장 비슷한 계열이지만, 마지막 릴리스 v0.17.0이 2021년 9월이고 README가 언급하는 지원 PostgreSQL도 9.6에서 15까지에 멈춰 있다. 활발히 개발되고 있다고 보기 어려운 상태다.
CloudNativePG는 비교 대상이라기보다 다른 층위의 답이다. Kubernetes operator로서, README가 “Patroni, repmgr, Stolon 같은 외부 HA 도구에 의존하는 대신 Kubernetes API와 직접 통합한다"고 밝힌다. failover 판단 주체가 각 노드의 agent가 아니라 operator다. Kubernetes 위라면 Patroni 기반 operator와 CloudNativePG 계열 사이의 선택이 되는데, CloudNativePG 쪽은 별도 노트에서 다루고 있다.
에코시스템
Patroni를 직접 설치하는 것 외에 포장된 형태로 쓰는 길도 여럿이다.
- 컨테이너 이미지: Spilo(Zalando가 유지하는 PostgreSQL + Patroni appliance), Crunchy Container Suite, CYBERTEC-pg-container
- Kubernetes operator(Patroni 기반): Zalando postgres-operator, CYBERTEC PG Operator, Crunchy PGO, Percona Operator for PostgreSQL, OnGres StackGres
- bare-metal:
pip install patroni[etcd]같은 pip 설치, 또는 apt.postgresql.org / yum.postgresql.org 배포판 패키지
Zalando postgres-operator의 기반 이미지가 Spilo다. Kubernetes에서 Patroni를 만나는 대부분의 경로가 이 두 프로젝트를 거치는 셈이다.