Have chatted with the guy who builds kubegres, it’s a really solid solution and is meant to be better integrated (CRDs) and more of the reliable parts of the pg stack.
It looks super solid. Unfortunately I can’t vouch for it in production yet since I still write my own resources but for me Zalando is #1 and Kubegres is either 2nd or 3rd.
We abandonded Zalando after failing to set it up properly. Don’t remember the details, but do remember that the setup is leaning towards the internal infrastructure at Zalando.
I personally preferred Zalando for the following reasons (this is from quite early on, when Zalando and Crunchy were the only options and differed more in approach):
- Focus on CRDs versus outside tools (crunchy used to insist on pgo and while it's not required, I don't really want another CLI to manage/use)
- Amount of open conversation, conference talks etc around Zalando's solution and why they've built their solution/how they've scaled it
- No specific need for pgadmin/badger/extra logging features (I might feel differently these days!)
- Customizable pods
These days both of these projects are very similar overall, and I haven't compared them recently.
These days I might lean Crunchy -- but a lot of the things that would be gaps (like no built in postgres support) I would actually opt to solve myself with a different operator (ex. Prometheus Operator) or just adding a deployment myself (when needed). Taking another quick look today, the differences I see are:
- customizable tablespaces with Crunchy
- local backups with pgbackrest + crunchy (and in general wal-g is preferred to wal-e so zalando is a little behind there)
Neither of them have citus though, which I think will be a huge game changer as a default-include for their pg images.
It looks super solid. Unfortunately I can’t vouch for it in production yet since I still write my own resources but for me Zalando is #1 and Kubegres is either 2nd or 3rd.
https://www.reddit.com/r/PostgreSQL/comments/mqrsbn/kubegres...