cloudnative-pg VS postgres-operator

My holiday project was doing another pass at my Homelab Kubernetes cluster, part of which involved switching to a proper operator to manage Postgres. Coincidentally, I setup cloudnative-pg (https://github.com/cloudnative-pg/cloudnative-pg) yesterday.

https://github.com/cloudnative-pg/cloudnative-pg/issues/13

/? logical replication:

https://www.google.com/search?q=logical+replication

pgadmin docs > Publication Dialog; logical replication: https://www.pgadmin.org/docs/pgadmin4/development/publicatio...

https://github.com/dalibo/pg_activity#faq ; pip install `pg_activity[psychopg]` :

> FAQ: I can't see my queries only TPS is shown

Only the TPS

(How) Do any ~pg_top tools delineate logical replication activity?

pgcenter > PostgreSQL statistics [virtual tables] (and also /proc)

We already had backup and recovery using object storage, but we are working to support VolumeSnapshots taking care to properly shut down the instance first! This awesome PR is laying the foundation for it, it's adding a subcommand to our kubectl plugin to manually perform a backup using VolumeSnapshots and adding support for restoring a Cluster from it, next step will be adding it to the ScheduledBackup/Backup resources too!

I'll ask in their slack channel later. I've also opened a discussion regarding this on github if you are interesed. https://github.com/cloudnative-pg/cloudnative-pg/discussions/2030

This has a bunch of side-effects that break usual expectations around scheduling. For instance, cluster scale-down (for maintenance etc.) is blocked unless a specific taint has been added to each database pod. In addition, if the underlying node does fail, your cluster will be stuck in fail-over state until you manually delete the underlying pods. I think there are definitely other gotchas around this decision to use a custom controller but I have only tested this on GKE.

Another option would be https://github.com/cloudnative-pg/cloudnative-pg I got to see this talk at Kubecon last month that might be of use to you too -> https://www.youtube.com/watch?v=99uSJXkKpeI That talk is run in part by EDB, who are the company behind CloudNativePG, they are talking about their commercial offering, but the principle is the same.

Following another post on this sub, I was checking out the Github project and landed on this 2864 lined CRD https://github.com/cloudnative-pg/cloudnative-pg/blob/main/config/crd/bases/postgresql.cnpg.io_clusters.yaml. How are sane people reading these files?

**NOTE**: I am a maintainer of CloudNativePG.

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.