postgres-operator VS patroni

yes, precisely. It's UI part that's broken, which cannot list snapshots. Issue is here, no fix since 2020, sadly: https://github.com/zalando/postgres-operator/issues/937

I personally like the Zalando operator better, you can add databases and users by updating the CRD, feature parity between the two on HA is pretty good

https://github.com/zalando/postgres-operator

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)

git clone https://github.com/zalando/postgres-operator.git cd postgres-operator

Zalando / Postgres-Operator

Somewhere between here and here i found out about that.

Here's an example of using the PostgreSQL Operator to deploy a high availability PostgreSQL cluster in Kubernetes. In this example, I'll be using the PostgreSQL Operator from Zalando [https://github.com/zalando/postgres-operator] to deploy a PostgreSQL cluster with two nodes.

Here's the operator for a postgres cluster: https://github.com/zalando/postgres-operator

And that repo you linked to has 1846 issues, 161 open. Which doesn't seem extraordinary based on my limited exposure to k8s.

Another example: https://github.com/zalando/postgres-operator/issues with 445 open issues. Why?

Maybe I'm wrong and this is all a good sign of progress, but my impression is that the entire k8s ecosystem is held together with reused duct tape.

> I think etcd is basically a k8s only project now

I hate etcd with the best of them, but etcd is used in a lot more places than just kubernetes:

https://github.com/apache/apisix/blob/master/docs/en/latest/...

https://github.com/traefik/traefik#:~:text=Etcd,

https://github.com/zalando/patroni#patroni-a-template-for-po...

https://github.com/purpleidea/mgmt/tree/0.0.26/etcd (this one shows up on HN quite a bit)

https://github.com/sorintlab/stolon#features

It's actually one of the major reasons I wouldn't touch those projects

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