Anyone can provide Postgres, MySQL or other open source databases as a service.
For this reason, there are many providers to choose from, and there is a healthy amount of innovation and competition in the space. Prices are set by market and demand, as it should be.
And then there is MongoDB where only a handful of providers could negotiate a license, and the price is set by MongoDB Inc.
In my opinion this is by no means "fine" from a user perspective as we are talking about database software.
If anyone did freeriding, it is MongoDB Inc. who chose to freeride on the open source community for marketing purposes, before switching to SSPL.
I am not sure if any hate is warranted, but it is true that coming up with a new license which does not comply with open source licenses, and proceeding to call it open source definitely did not help to create sympathy.
There is nothing wrong with releasing something under a proprietary license but calling this license change "Doubling down on open source" is damaging.
It tends to be a spectrum, but the various, sometimes very different licenses adopted by the OSI still have something in common - the open source values laid out in the Open Source Definition. [1]
SSPL did not comply with this requirement, as it discriminate against specific users or use cases. I think it is in the interest of everyone to draw the line somewhere.
It's a little more complicated than than just having to refrain from selling MongoDB services. There is a good page which summarizes the problem with SSPL. [1]
SSPL is crafted in a way that it very hard to tell whether you comply with the license or not, especially if you run it as part of a cloud hosted solution.
Yes this is one of the reasons we started FerretDB. Atlas is very easy to use, but it is nearly impossible to move away from later on, as there is no alternative (unless you are ready to rewrite your app). We think that most of its killer features, like easy sharding, can be done with Postgres and/or SQLite.
The key to success here seems to be a standardized OSS app store. Somehow.
On the other hand, I feel like the Raspberry is no longer a good platform to build on. It is impossible to buy, and when you can, it is going for many times over any reasonable price.
Yes, building an extension is something we are looking at, and I am glad to hear that you would be interested in this kind of mixed use case. Would definitely make things interesting, and more performant.
Thanks for the feedback. Any managed Postgres-compatible database which offers autoscaling works with FerretDB. You don't have to manage the Postgres side if it is already managed [1].
One example would be Yugabyte which is not yet officially supported, but was tested by Yugabyte with FerretDB. Same goes for CockroachDB, which was also tested to some extent. Neon would work, too.
On the other hand, FerretDB may not be a solution for all possible use cases out there, but no database is.
FerretDB maintainer here. We consulted the ToroDB team before we started FerretDB, as we wanted to understand why they couldn't conquer the world. They were way ahead of their time. And what a cool logo!
Our development roadmap [1] is based on the needs of the users and the software we are focusing on building compatibility with.
Interestingly, transactions are not commonly used and therefore it is not high on our priority list, it may take months until we get to it. Nevertheless, if enough users would request it, we would reconsider. The same goes for any other item on the roadmap, please check it out.
Just curious: what are your specific reasons for not liking the company behind MongoDB?