Postgres Kubernetes operators
The Kubernetes section of awesome-postgres, all nine entries, as catalogued on 2026-08-20, at the catalog's word (T3).
| Entry | Catalogued as |
|---|---|
| CloudNativePG operator | Comprehensive Kubernetes management |
| Crunchy Operator | Production PostgreSQL on Kubernetes |
| Zalando Operator | Creates and manages PostgreSQL clusters |
| StackGres Operator | Full-stack PostgreSQL on Kubernetes |
| Kubegres Operator | Deploy clusters with replication management |
| Percona PostgreSQL Operator | Based on the Crunchy Data operator |
| Percona Everest Operator | Unified management for multiple databases |
| KubeDB operator | Production-grade databases on Kubernetes (commercial) |
| Fujitsu Enterprise Postgres | Enterprise-grade on OpenShift (commercial) |
Scope note. Running a database as a Kubernetes workload is the SRE practice ../platform-ops-wiki
owns. The reason this page sits here instead is that the architecture underneath most of these
operators is patroni's, which is a database-architecture fact.
What an operator actually adds
patroni already solves leader election and fencing by holding a TTL'd lock in a distributed configuration store — and one of its four supported stores is the Kubernetes API itself, which means a Kubernetes cluster provides the consensus layer for free. What the operator adds on top is the lifecycle: provisioning pods and volumes, rolling upgrades, backup scheduling, and connection endpoints that follow the leader.
The zalando operator is the direct descendant of the same team's Patroni work — noted on
patroni with the governance detail that zalando/patroni now redirects to patroni/patroni, so
the operator and the failover engine no longer share an owner.
The consequence worth carrying into ../platform-ops-wiki is that a "Postgres operator" is not doing
the hard part. The hard part is a lease and a watchdog, and it was solved outside Kubernetes; the
operator is packaging. Any of these nine that claims high availability as its own feature is
describing Patroni or an equivalent under a different name — which is a claim this page states as a
reading of the catalog's descriptions, not as a verified fact about all nine.
Next candidate
CloudNativePG, which is the one in this list generally described as implementing its own failover logic against the Kubernetes API rather than embedding Patroni. If that is right, it is a second independent design for the same job and a genuine comparison — and it needs a primary read to confirm, because this catalog line does not say so.
Related
patroni · zalando · postgres-ha-tooling · postgres-managed-services · awesome-postgres · operational-databases