Before using Crunchy Data, I'd read their terms of use.
"without an active Crunchy Data Support Subscription or other signed written agreement with Crunchy Data are not intended for... using the services provided under the Program (or any part of the services) for a production environment, production applications or with production data"
If you look at their Docker Hub images, you'll see that they're provided under the terms of use of the Crunchy Data developer program which means you can't use them in production without an active subscription.
Maybe I'm reading it wrong, but if that's the case Crunchy Data should definitely change their terms of service.
Percona certainly seems to think you can't use the Crunchy Data images in production saying, "CrunchyData container images are provided under Crunchy Data Developer Program, which means that without an active contract they could not be used for production."
It is more than "Percona Thinks" We have number of customers who started using Crunchy Kubernetes Operator based solution thinking it is Open Source and were contacted by Crunchy Sales team to indicate they need subscription to use it.
This was one of the reasons for them to move to Percona Operator for PostgreSQL which does not require any commercial relationship with Percona to use in practice and completely Open Source
I think this is more of the disclaimer that they are not responsible to any damage to your production systems if you do not use their support. That's why the wording is "are not intended for..." and not "you are prohibited from..."
If building a list of alternatives, let me do a shameless plug for StackGres [1], the Postgres platform for Kubernetes with a fully featured Web Console, AMD64 and ARM64 support and more than a hundred available Postgres extensions [2]. Fully open source, no usage restrictions.
One clarification about CloudNativePG. It is not EDB's anymore (or EnterpriseDB if you prefer).
EDB is the original creator. The software is now entirely owned by a vendor neutral community, openly governed. We have applied for the CNCF sandbox and waiting for the approval at this stage.
In case some of you are interested in learning more about running databases on Kubernetes, or more generally stateful workloads, there is a community dedicated to that https://dok.community/
I a am part of the community team. We have weekly live streams/blog posts about the topic and a Slack channel.
I used this in the past. Helped a lot with provisioning micro-pg-clusters.
But honestly, the project always felt like a one-man-show, some (realy great) dev had a working set of scripts and kubernetized / operatorized it, but the whole thing feels hacky as hell.
I'd still give a try if I ever needed postgresql again, but I would also know that I need to implement (again) my set of scripts and hacks on top of it.
Back then, we evaluated Crunchy Operator's source code. Being primarily imperative and using an external tool for failover, where the two main reasons we decided to start a new project in 2019 which was entirely declarative and purely based on the Kubernetes API server for cluster status. Such project was released open source last April under the name CloudNativePG and hopefully it will enter the CNCF Sandbox soon (fingers crossed).
I think this is a super interesting space.
What I mean by that is the fact we have Postgres, which is arguably one of the most successful publicly governed open source project out there, for many decades! That meats on of the most vibrant and transformative publicly governed projects as well, called Kubernetes (CNCF).
Why then consider a (proprietary) vendor governed (open source) project to bring these two technologies together? With CloudNativePG, you bring these two super strong communities together using these exact same governance principles, enabling everyone to benefit and contribute.
It is my conviction that this is going to be one of those elements that is going to contribute to the ongoing transformation of data management today.
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.
I cannot trust critical infrastructure components to 3rd party kubernetes operators. I don't like operators (I didn't write) in general because I find them too opinionated and obfuscated. It's unbelievable to me that someone would deploy a production datastore using one.
Regarding being opinionated I believe that it is what we expect from an operator. An operator simulates what human DBAs in this case would do. I am a maintainer of CloudNativePG, and I have been running and supporting PostgreSQL in production for 15+ years, creating also another open source software for backups (Barman). In CloudNativePG we have basically translated our recipes into Go code and tests.
Many people believe that databases should not run in Kubernetes. I not only believe the opposite, I believe that running Postgres in Kubernetes represents the best way, potentially, to run Postgres out there.
This survey (1) shows that the majority of orgs develop their own operators, perhaps related to what you say here. Do you think industry standards for operators would move things in the right direction?
mdasen|3 years ago
Before using Crunchy Data, I'd read their terms of use.
"without an active Crunchy Data Support Subscription or other signed written agreement with Crunchy Data are not intended for... using the services provided under the Program (or any part of the services) for a production environment, production applications or with production data"
https://hub.docker.com/r/crunchydata/crunchy-postgres
If you look at their Docker Hub images, you'll see that they're provided under the terms of use of the Crunchy Data developer program which means you can't use them in production without an active subscription.
Maybe I'm reading it wrong, but if that's the case Crunchy Data should definitely change their terms of service.
https://www.percona.com/blog/2021/05/26/percona-distribution...
Percona certainly seems to think you can't use the Crunchy Data images in production saying, "CrunchyData container images are provided under Crunchy Data Developer Program, which means that without an active contract they could not be used for production."
PeterZaitsev|3 years ago
It is more than "Percona Thinks" We have number of customers who started using Crunchy Kubernetes Operator based solution thinking it is Open Source and were contacted by Crunchy Sales team to indicate they need subscription to use it.
This was one of the reasons for them to move to Percona Operator for PostgreSQL which does not require any commercial relationship with Percona to use in practice and completely Open Source
https://www.percona.com/doc/kubernetes-operator-for-postgres...
988747|3 years ago
vbezhenar|3 years ago
New player from Enterprise DB: https://github.com/cloudnative-pg/cloudnative-pg
ahachete|3 years ago
[1] https://stackgres.io/
[2] https://stackgres.io/extensions/
Disclaimer: founder of the project.
bo0tzz|3 years ago
loganloganlogan|3 years ago
gbartolini|3 years ago
EDB is the original creator. The software is now entirely owned by a vendor neutral community, openly governed. We have applied for the CNCF sandbox and waiting for the approval at this stage.
qeternity|3 years ago
mdasen|3 years ago
Percona also has a PG operator.
sylvainkalache|3 years ago
I a am part of the community team. We have weekly live streams/blog posts about the topic and a Slack channel.
kmarc|3 years ago
But honestly, the project always felt like a one-man-show, some (realy great) dev had a working set of scripts and kubernetized / operatorized it, but the whole thing feels hacky as hell.
I'd still give a try if I ever needed postgresql again, but I would also know that I need to implement (again) my set of scripts and hacks on top of it.
gbartolini|3 years ago
Back then, we evaluated Crunchy Operator's source code. Being primarily imperative and using an external tool for failover, where the two main reasons we decided to start a new project in 2019 which was entirely declarative and purely based on the Kubernetes API server for cluster status. Such project was released open source last April under the name CloudNativePG and hopefully it will enter the CNCF Sandbox soon (fingers crossed).
smartbit|3 years ago
Couldn’t agree with you more, especially if you’re used to the quality of strimzi.
Johnnyq72|3 years ago
I think this is a super interesting space. What I mean by that is the fact we have Postgres, which is arguably one of the most successful publicly governed open source project out there, for many decades! That meats on of the most vibrant and transformative publicly governed projects as well, called Kubernetes (CNCF).
Why then consider a (proprietary) vendor governed (open source) project to bring these two technologies together? With CloudNativePG, you bring these two super strong communities together using these exact same governance principles, enabling everyone to benefit and contribute.
It is my conviction that this is going to be one of those elements that is going to contribute to the ongoing transformation of data management today.
Johnnyq72|3 years ago
noodlesUK|3 years ago
https://www.kubegres.io/
hardwaresofton|3 years ago
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...
uberduper|3 years ago
gbartolini|3 years ago
Regarding being opinionated I believe that it is what we expect from an operator. An operator simulates what human DBAs in this case would do. I am a maintainer of CloudNativePG, and I have been running and supporting PostgreSQL in production for 15+ years, creating also another open source software for backups (Barman). In CloudNativePG we have basically translated our recipes into Go code and tests.
Many people believe that databases should not run in Kubernetes. I not only believe the opposite, I believe that running Postgres in Kubernetes represents the best way, potentially, to run Postgres out there.
loganloganlogan|3 years ago
(1) https://dok.community/wp-content/uploads/2021/10/DoK_Report_...