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.
Looking back at my notes I had this written down:
> Looks like Zalando is probably the winner (https://www.youtube.com/watch?v=WBdNVrffOSo)
The video is old and in Japanese but basically:
- scale in/out are similar
- RBAC control is similar
- Automatic version upgrades (only Zalando supported rolling update at the time)
- Zalando had PVC-driven volume resize vs Crunchy required cluster change
It's been a year so maybe they're probably even more similar now but I'd love to hear what I'm missing if I'm wrong.
Some more resources:
https://blog.flant.com/comparing-kubernetes-operators-for-po...
https://www.youtube.com/watch?v=3TFXztwat_s
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.
