[hardwaresofton]

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.

https://www.reddit.com/r/PostgreSQL/comments/mqrsbn/kubegres...

[smartbit]

Could you elaborate why Zalando is #1?

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.

[hardwaresofton]

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.

[gbartolini]

As maintainer of the project, I suggest looking at CloudNativePG, which is production ready (cloudnative-pg.io).

[hardwaresofton]

Super late, but just got a chance to take a look -- maybe worth a mention that it's started by you folks over at EDB!

Feels like all the Postgres enterprises are making kubernetes operators these days -- probably seeing it as a way to stay in the game/relevant.

Just like before when I benefited from EDBs contributions to pg as a whole (and advancing the cause of pg), I look forward to benefiting again!