patroni VS postgres-operator

Citus doesn't provide fault tolerance. Each shard is a monolithic PostgreSQL. To reduce downtime on failures, you can protect each shard with a standby database. As this is a complex configuration, Patroni can help. For this lab I'll use the Citus+Patroni docker-compose-citus.yml from https://github.com/zalando/patroni.git:

We have been using stolon + consul for years without issue in our swarm environments. It may also be possible with patroni.

one of the solutions which made it pretty simple for us to run postgresql in a ha environment (mostly in k8s, but works standalone as well) is zalandos patroni: https://github.com/zalando/patroni it's really solid and worked for us for a few years already.

or for k8s their operator: https://github.com/zalando/postgres-operator (docker image: https://github.com/zalando/spilo) we've also tried other operators which were easier to get started, but they failed miserably (crunchyrolls operator is basically based on the zalando one)

Hello. I am currently using this docker-compose model from Zalando repository. It does not include PgBouncer in its architecture by default. I've been trying to find a containerized implementation involving Patroni, HAProxy, Etcd and PgBouncer. I didn't find anything solid so far.

General purpose: Patroni - Set up your own etcd + HAProxy + Patroni + Postgres components and it'll generally manage itself after that.

I don't have a great answer for you except that it sounds like you are trying to create your own version of patroni. Is there a good reason to not just use patroni?

git clone https://github.com/zalando/patroni.git cd patroni docker build -t patroni . docker-compose up -d

I actually used Patroni on Openshift in my company. To be update with the latest version we created our helm chart.

As for the Operators, I've been using Crunchy PGO, which is very high quality, and one of the most widely used. You can install it via Helm, or via OLM from OperatorHub. There are other good ones as well, but none that I have experience with. The only issue I've run into so far is I've had to disable TLS on the database cluster, as Prowlarr refused to connect with it for some reason (Radarr was fine). I still need to open an issue with the Prowlarr team about that, but I might switch to a service mesh for TLS anyway.

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?

On the topic of Postgres, you should look into an operator or Helm chart that can setup common things (like replication and auto-failover), such as Crunchy's Postgres operator, or consider using a "cloud-native" distributed database like CockroachDB (disclaimer: I am a Cockroach Labs employee) which has its own operator as well. Another word of warning, running stateful services, particularly mission critical databases, can require a lot of maintenance work (it's my full-time job), so unless this is for a hobby project, I would highly recommend you look into using a managed database offerring. Every major cloud provider and most database companies have one.

For postgres you can also have a look at PGO or bitnami helm chart

Let's say a new Kubernetes version comes out in April. In November, as everything works perfectly well, you decide to install a Postgres operator on it. Bummer, it doesn't work. It's not a huge issue, you just wait until the bug is resolved (already done[0]), but it's just one of these tiny things that I don't get when running Postrges natively. And I'm saying this as a big fan of Crunchy Data running some production loads on it without a failure for quite some time now.

[0] https://github.com/CrunchyData/postgres-operator/issues/3476

There is one particular client that have a somewhat big database 40-120gb (it change size over the year), and for that we used CrunchyData Postgres operator ( https://access.crunchydata.com/documentation/postgres-operator/v5/ ) we have no commercial relation with them, but oboi let me tell you the god send that thing is, this database in specific process massive data and it is distributed between several nodes in a read-write and read-only set, and let me tell you, it is amazing how easy it is to move things around, take backups, increase the capacity and a bunch of other goodies that operator bring. Give it a try.