patroni VS postgresql_cluster

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.

Creating a robust and reliable database cluster is often fraught with challenges.A manual deployment process can be fraught with risks, particularly for those who lack extensive experience. Even minor errors in configuration can drastically affect your database's performance and stability.

Recognizing this intricacy, many businesses choose to use cloud-based managed databases. These services offer convenience but not without limitations. These drawbacks can include being tied to a specific cloud provider and limited direct access to the database server for adjustments. These constraints can hinder your ability to tune your system and perform thorough performance analyses.

In response to these challenges, we've developed a project to make this process easier and more efficient. This project uses automation to streamline the deployment of High-Availability PostgreSQL Clusters. By doing so, it helps mitigate the risks involved with manual configuration and speeds up the deployment process.

Our solution caters to various deployment environments. It allows you to establish your cluster either in your own data center or in the cloud, providing a robust database solution similar to managed databases, but with you retaining full control.

Explore the project here: https://github.com/vitabaks/postgresql_cluster

FYI: postgresql_cluster

HA postgres

If not Kubernetes, check out this: https://github.com/vitabaks/postgresql_cluster – Postgres + patroni + pgBouncer + WAL-G or pgBackRest + Netdata + more, managed by Ansible.

If you do want to use Kubernetes, then check out StackGres.io and https://github.com/zalando/postgres-operator

Also check PostgreSQL High-Availability Cluster (based on "Patroni" and "DCS(etcd)"). Automating deployment with Ansible.