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."
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...
We decided to go even further with the CloudNativePG operator.
EDB as original creator has decided to donate the intellectual property of the source code to the community, open sourced the existing operator under Apache License 2.0 to apply for the CNCF Sandbox. The project not only includes the operator, but also the PostgreSQL operand images - which can be customized (we provide details on how images should be).
We genuinely welcome other vendors to participate in the community and contribute to the project, including by offering professional services around it. Our multi-year commitment is to become a graduated CNCF project.
For more information: https://cloudnative-pg.io/
Basically, the license seems to be (and IANAL): we provide the software for development purposes...without a subscription, it's only intended for development purposes
They didn't say "we provide this software for your use...without a subscription, it's only intended for development purposes". They basically said: we provide this software for development purposes, it's only intended for development purposes.
If it's only a disclaimer, where's the grant of rights to use the software beyond development purposes?
Yes, if I were a lawyer defending a user, I'd definitely be arguing your point. However, I think Crunchy Data's lawyer would simply point out that there's literally no grant in the license for non-development purposes. Maybe a judge would take pity on you given that it seems hidden, has some ambiguity (though maybe it's not ambiguous to a lawyer), and because they allow you to spin up the operator basically without ever knowing these terms exist.
Given that there are many other PostgreSQL operators from companies like Percona (which I think has a great and long track record of supporting open source databases), EnterpriseDB, and Zalando, I don't see why I'd want to choose Crunchy Data.
You might be right and I think you would be right if only looking at the piece I quoted, but given that there's no general grant in the license that the "intended for" is merely a disclaimer for, it seems like the license grant is that they provide access for development purposes. IANAL and I'd rather work with software and companies where I don't have to be a lawyer. Crunchy Data could have said "We provide access to this software free of charge for any purpose. Without a subscription, it is unsupported and not intended for production use. We are not responsible for anything that happens if you use it in production." That's not what they said. They said that they provide it "free of charge for development purposes" with no grant for non-development purposes.
New player from Enterprise DB: https://github.com/cloudnative-pg/cloudnative-pg
[2] https://stackgres.io/extensions/
Disclaimer: founder of the project.
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.
Percona also has a PG operator.
I a am part of the community team. We have weekly live streams/blog posts about the topic and a Slack channel.
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.
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...
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.
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.
I've run into way too many exotic edge cases with kubernetes to trust an operator to do the right thing with data I care about. Most especially when the operator is also managing the replication and replicas and their underlying storage.
I am pro running datastores and other stateful workloads on kubernetes. I've been running databases on kubernetes since petSets.
(1) https://dok.community/wp-content/uploads/2021/10/DoK_Report_...
