| 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. |