peterfarkas

Thanks for posting and glad you liked the project (FerretDB maintainer here).

Just curious: what are your specific reasons for not liking the company behind MongoDB?

Around the world means a couple random countries in this case. Also it includes the sales tax seemingly everywhere, except the US.

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.

https://logz.io/blog/open-source-elasticsearch-doubling-down...

Thanks for the very relevant plug, we are going to test with Marmot.

Maintainer here. We will try in the next few days, and I will let you know. I have a lot of Unifi stuff myself.

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.

[1]: https://opensource.org/osd/

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.

[1]: www.ssplisbad.com

Thank you, we will take a look!

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.

Maintainer here. That's a very good idea! Let us know if you ever have some time to work with us on this.

Maintainer here, thanks for posting!

Latest is 1.3.0, since 1.1.0 we added experimental support for SQLite, among other things.

In the coming versions FerretDB will enable you to run MongoDB workloads using FerretDB+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.

Maintainer here, thanks for submitting. Funny how the first comment, even on under this article, is always the "Is it Webscale?" video.

Tigris is using FerretDB to achieve MongoDB compatibility.

The MongoDB compatibility code under the hood is FerretDB.

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.

FerretDB maintainer here: we are working on it. We are already getting reports of successful migrations with Meteor apps. [1]

Would you mind sharing the specific Meteor app you are looking to get supported?

MeteorJS is among the most requested applications/frameworks our users are looking to use with FerretDB.

[1]: https://twitter.com/CowboyCaramel/status/1646089964126347264

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.

[1]: https://dev.to/aws-heroes/ferretdb-yugabytedb-on-kubernetes-...

https://dzone.com/articles/migrating-mongodb-collections-to-...

https://dzone.com/articles/using-cockroachdb-as-a-backend-fo...

https://dzone.com/articles/experimenting-with-unique-constra...

https://dzone.com/articles/cockroachdb-multiregion-abstracti...

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.

[1]: https://github.com/orgs/FerretDB/projects/2

SSPL goes way beyond AGPL as it contains an additional clause called "Offering the Program as a Service". It is not defined at all what constitutes providing MongoDB as a service. How many layers are needed to abstract MongoDB in a way that it doesn't trigger this clause? There are no answers for that in the SSPL. It comes with an enormous amount of risk compared to AGPL. There is a good article from Dor Laor at ScyllaDB which explains this in detail [1].

Moreover, cloud providers are not limited to AWS, Azure and GCP. Smaller providers whom we talked to are not able to negotiate licensing terms with MongoDB the same way as how AWS could. For this reason, these providers are not able to provide MongoDB as a service. Yes, it's great for MongoDB that they were stopped from providing MongoDB for free, but now they can't provide the service at all. This limits competition and choices, and that is never in the favor of users.

[1]: https://www.scylladb.com/2018/10/22/the-dark-side-of-mongodb...

Exactly. Let's say a major company have a few applications which require MongoDB, and the rest of their applications are running on Postgres.

With FerretDB, they can migrate the app off MongoDB as you said, and keep Postgres only. Therefore they don't need to maintain internal knowledge on how to run MongoDB, or pay for MongoDB to run it for them (in which case they are not in control of their data, because it is all under MongoDB's account...).

This is one real world user example.

Yes, FerretDB is a layer which implements the MongoDB wire protocol on top of Postgres. Right now we are using JSONB, but this affects performance and we need to depart from this strategy in the long run. We have an article which explains the concept [1].

I wouldn't go into the document vs. relational argument, all arguments for and against would have merit. There are valid use cases for document databases (take e-commerce, for example), and we should not discount the fact that using a relational database is just more complicated. Using vanilla Postgres for a MongoDB use case will not be feasible for someone who's focus is, let's say, mobile application development. There is a reason behind MongoDB's popularity - it just provides a great developer experience. This is what we are aiming to recreate on top of Postgres.

[1]: https://blog.ferretdb.io/pjson-how-to-store-bson-in-jsonb/

While I do respect your opinion, I disagree.

I think that arrogance is when a single vendor tries to single-handedly redefine open-source to fit their business needs better. Not just a license, but the definition itself.

A quote from the MongoDB CEO: "MongoDB was built by MongoDB. There was no prior art. We didn't open source it for help; we open sourced it as a freemium strategy". [1]

Whether the OSI was arrogant or not, I really don't want this person to define opensource.

[1]: https://techmonitor.ai/leadership/strategy/mongodb-ceo-inter...

By definition, SSPL is not an open-source license [1].

One could argue that the SSPL brings justice to open-source, as cloud providers will not be able to monetize a project without giving anything back. SSPL forces them to pay a license fee.

On the other hand, this also creates a vendor lock-in situation for the user, simply because not all service providers will be able to negotiate a deal with the developer of the SSPL-licensed product. This limits choice, limits competition between providers, among other things.

This license fee may also be increased at the sole discretion of the developer, and the increased fee will be paid by the user in the end. This all doesn't sound open-source to me at all.

[1]: https://blog.opensource.org/the-sspl-is-not-an-open-source-l...

FerretDB maintainer here.

We already offer basic support for aggregation and indexing, and we are adding as many features as we can, see our roadmap [1].

We are mainly building on our user's experience with running FerretDB and add features to our roadmap accordingly. We are not aiming to implement the entire feature set of MongoDB, of course, but the majority of MongoDB workloads are not utilizing the full feature set, either.

[1]: https://github.com/orgs/FerretDB/projects/2/views/1

It’s been a while since FerretDB (well, we were called MangoDB back then) was first posted on HN. Back then, it was nothing but a tech demo - today, FerretDB is being used in production.

We’ve received a lot of great feedback on HN, which we used to set the direction of our project. So it’s only natural that we want to show HN what we used your input for. Please give it a try and let us know how it went. Read more about the new release in our blog post.[1]

As a recap, FerretDB is an open source alternative to MongoDB. We started building it because we believe that there should be an OSS alternative to MongoDB, as they changed over to the proprietary and controversial SSPL license [2]. We built it on Postgres, because we believe that Postgres as a backend is more than capable of playing the part. FerretDB is written in Go; it also can be used as a Go library.

We started adding support for SQLite as well, as there is a lot of interest in it.

Our long-term goal is to create an open standard for document databases, similarly to how SQL is a standard for interfacing with RDBMS.

[1]: https://blog.ferretdb.io/ferretdb-1-0-ga-opensource-mongodb-...

[2]: https://blog.opensource.org/the-sspl-is-not-an-open-source-l...

I've read about this and it surprised me that concrete-encased steel could not be inspected in the case of the Morandi bridge. X-ray, or measuring how conductive it is should work.

Just don't change it to Dumbotron, however attractive it may sound :)

What a time to be alive. This should be disclosed on the front page of the manual and not hidden in the smallprint. And it should come with instructions on how to disable it with a physical switch.