Pgo: The Postgres operator from crunchy data

Thank you!

Yes. We have development version available already, check it out and give us some feedback - what else need to be done so it is Production Ready

I agree that the developer program ToS is written in a confusing manner and suggests that you can't use it all for production without a license. I expect that to be intentional: if the impression you get is that you can't even use their software in production, it's much less likely that you will do so with the impression that there is any support, warranty, or endorsement of such use.

[EDIT: I made an error, I originally said that it was explicit about no license being granted for the software, but that was about things like no license for service marks and trade names.]

On the other hand, there is a license for postgres-operator and it looks like Apache 2.0:

https://github.com/CrunchyData/postgres-operator/blob/master...

For what's being distributed in their Docker container image, I imagine it depends on what they're actually distributing for that to matter. I expect that it's mostly other people's software (like PostgreSQL) and that the Docker page listing the container just too much of a summary to say anything about licensing. I'd investigate that further to clarify license status prior to use, but expect it to not be legally constrained to non-production use only.

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.

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!

I agree with your view point and concerns.

That is why we took the approach to reduce the number of components and integrate everything in Kubernetes, especially with logging (we directly log in JSON to standard output) and the usage of application containers, which enables us to cover the case of troubleshooting via the fencing mechanism (your pods are up, you can access storage, but Postgres is down, giving you the possibility to check even possible data corruption issues).

Also, the status is directly available in Kubernetes, so in our view easier for Kubernetes administrators.

Finally, the source code is open source and directly available for inspection - if you want to understand what is happening.

So, instead of (re-)inventing the wheel, with something like CloudNativePG, I would encourage your team to look into this, perhaps help contribute to better documentation. I believe that would be the way to a) get your project to benefit from using an operator for Postgres (hence scaling / benefitting more and more quickly) and it would b) help a great bunch of other folks to also benefit from that shared knowledge.