postgresql_cluster VS patroni

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.

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.

This is why I always recommend using a postgres proxy so you can point it to different database servers as you stand them up. AWS does this by default but GCP doesn’t yet, so you have to have your own Postgres proxy (e.g https://github.com/CrunchyData/crunchy-proxy) or move to an HA Postgres setup like Patroni that has streaming replication (https://github.com/zalando/patroni).

Want a tool for increasing the durability of your DB? I suggest running postgres via systemd, or failing that, start-stop-daemon. To get even more robust, look in to something like setting up pgbouncer in front of haproxy in front of a set of read-only replica PG instances running in either logical or streaming replication. To get even MORE robust, I suggest Patroni for high-availability PG.

see here - https://github.com/zalando/patroni