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.