-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Evaluate operator alternatives #27
Comments
We should also evaluate https://github.com/CrunchyData/postgres-operator |
@Racer159 the CrunchyData operator has some weird license things that made us decide against using it. I forget what exactly, but I just remember it made it a no go for us |
We used CNPG at my last company, and we had a great experience with it. We referenced this HN thread to get people's comparison impressions as part of the decision. The quotes from it that stood out to us:
|
Can confirm the "Documentation all over the place" part, working with zalando postgres operator at any level higher than make work as database (backups) is an absolute nightmare |
Another issue... it seems after pepr mutates the security context the postgres operator keeps detects and keeps reapplying it's own annotations. It creates an infinite loop between the operator and pepr. Related issue: zalando/postgres-operator#2223
|
Describe what should be investigated or refactored
There currently isn't much ADR history for the choice of the Zalando postgres operator. We should evaluate CloudNativePG as it is more directly supported by the PG project itself.
Links to any relevant code
https://github.com/cloudnative-pg/cloudnative-pg?tab=readme-ov-file
Additional context
If we do not decide to use CNPG we must document the why in an ADR.
The text was updated successfully, but these errors were encountered: