Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
postgres-operator
Production PostgreSQL for Kubernetes, from high availability Postgres clusters to full-scale database-as-a-service. (by CrunchyData)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
postgresql_cluster
PostgreSQL High-Availability Cluster (based on "Patroni" and DCS "etcd" or "consul"). Automating with Ansible.
General purpose: Patroni - Set up your own etcd + HAProxy + Patroni + Postgres components and it'll generally manage itself after that.
Simplified and probably OK: pg_auto_failover - One Monitor/Witness node and minimum services otherwise. Good documentation to get started and not nearly as complex as Patroni.
PgCluster - Look at the commits. This project is dead.
RubyRep - Look at the last commit; this is also a dead project. In any case, anything "database agnostic" isn't really suitable for failover, IMO.
Citus - Citus is very much alive and is a thriving open-source and commercial product, but is not HA on its own. It is essentially distributed/sharded Postgres.
The Crunchy operator, seemingly like most (if not all) of the other Postgres operators (Zalando, KubeDB, and StackGres, etc.), is essentially a wrapper for Patroni. IMO if someone wanted a Patroni cluster, they would just build one. The point of an operator is to manage the cluster resources and node relationships, so why not have it take the role Patroni is filling here? It's already reaching into the nodes, obtaining status, managing the routing, etc., so why add the extra layer?
HA postgres