What does HackerNews think of postgres-operator?

Postgres operator creates and manages PostgreSQL clusters running in Kubernetes

Language: Go

#10 in Go
#7 in Kubernetes
#8 in PostgreSQL
#10 in PostgreSQL
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

As far as I understand Zalando does this. They have their own PostgreSQL operator https://github.com/zalando/postgres-operator.
In Kubernetes a service call end an operator watches for CRD specifying databases to be created and manages upgrade and backs for those databases.

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

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

If you do want to use Kubernetes, then check out:

- StackGres.io

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

- https://blog.flant.com/comparing-kubernetes-operators-for-po...

I'm curious if you've looked at https://github.com/zalando/postgres-operator and had thoughts on how it compared. The CrunchyData operator seems to use Patroni and links to the Patroni documentation which links to the Zalando Postgres Operator from the same company as Patroni.
on k8s there is:

- crunchydata - the thing crunchy is based on (well actually they are more based on the underlying things like patroni): zalando postgres operator https://github.com/zalando/postgres-operator, really really solid stuff

Right, and operator from Zalando https://github.com/zalando/postgres-operator (fresh good comparison, in Russian, but google translate should work well on such texnical texts https://habr.com/ru/company/flant/blog/520616/).

All of them look interesting and developing rapidly.

I'm curious, did you use Patroni directly on Kubernetes or use Zalando's Postgres Operator [1] (based on Patroni)? [1] https://github.com/zalando/postgres-operator
Backups, configuration and failover. Which traditionally meant a db guy or an ops guy which costs money. I've done it for multiple database technologies and doing it right is not at all easy or cheap on time.

With that said, Kubernetes might fix this because they have access to more parts of the system in a generic API. With tech like KubeDB[1] and other operators[2] we might see these prices coming closer to bare-metal.

[1] https://kubedb.com/ [2] https://github.com/zalando/postgres-operator

I work at Zalando where we run hundreds of PostgreSQL database clusters on Kubernetes (on AWS) using our Postgres Operator (https://github.com/zalando/postgres-operator). This gives us some added flexibility, quick startup (e.g. for e2e), and the latest PG features. That being said, I would be careful to recommend any specific stateful workload approach without good understanding of the whole setup (true for whatever cloud/k8s/onprem environment).