One thing that I didn't see discussed was why FerretDB uses Postgres as a backend and not a storage engine. Perhaps I am just missing something though.
FerretDB: open-source MongoDB alternative
31–40 of 130 posts
Re: FerretDB: open-source MongoDB alternative
#32Earlier quoted context omitted.
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…
MongoDB’s source code is still freely available. It’s still actively developed in the open on GitHub. Unless you’re offering MongoDB as a service, it’s just as “open source” as ever. If you want to offer MongoDB as a service, you can still do so free of charge, as long as the service infrastructure is also made openly available, right? And if you don’t want to make the source available, you can purchase a license and…
> If you want to offer MongoDB as a service, you can still do so free of charge, as long as the service infrastructure is also made openly available, right?
The license text is worded as such that it is basically impossible to comply with.
> OSI’s “MongoDB isn’t open source anymore” campaign work so well.
It is hardly OSIs campaign. Pretty much all major organizations involved in FOSS licensing have rejected sspl. For example this is Fedoras stance:
> Fedora considers the Server Side Public License (v1) to be a Non-Free license. It is the belief of Fedora that the SSPL is intentionally crafted to be aggressively discriminatory towards a specific class of users. Additionally, it seems clear that the intent of the license author is to cause Fear, Uncertainty, and Doubt towards commercial users of software under that license. To consider the SSPL to be "Free" or "Open Source" causes that shadow to be cast across all other licenses in the FOSS ecosystem, even though none of them carry that risk.
Re: FerretDB: open-source MongoDB alternative
#33If it can run a replica set on an apple m1 which mongo can’t currently do then great!
Er, why can’t you run a MongoDB replica set on your M1?
I mean, I wouldn’t recommend running a ReplicaSet on the same host on any production host (it defeats the purpose), but for testing, I’ve run a sharded cluster w/ 3 replicas per shard…
Happy to try and help!
Re: FerretDB: open-source MongoDB alternative
#34One thing that I didn't see discussed was why FerretDB uses Postgres as a backend and not a storage engine. Perhaps I am just missing something though.
Because PostgreSQL Is fantastic Open Source database engine, very popular with a lot of operational experience and tooling support.
This is Open Source way of doing things - having project focus on as narrow problem as possible (first) and leverage as much of existing componets as possible.
Re: FerretDB: open-source MongoDB alternative
#35Earlier quoted context omitted.
MongoDB’s source code is still freely available. It’s still actively developed in the open on GitHub. Unless you’re offering MongoDB as a service, it’s just as “open source” as ever. If you want to offer MongoDB as a service, you can still do so free of charge, as long as the service infrastructure is also made openly available, right? And if you don’t want to make the source available, you can purchase a license and…
"You can do so as soon as you open source infrastructure" is impractical and misleading. It is very likely part of infrastructure will be commercially licensed so even if one would want to open source it, it would not be possible. MongoDB Specifically switches from Open Source License to SSPL to create monopoly in DBaaS Space. IT is business decision so lets not pretend here. If you look at Real Open Source software…
Er, if you develop the infrastructure to host MongoDB, you should absolutely be able to open-source that infrastructure. I mean, before MongoDB, I wrote a cluster management system for virtualized software security and hypervisor research, and all of it was either open source or something I wrote…
Also, if you bought something closed-source to sell MongoDB as a service, why isn’t it realistic to buy a license?
Your suggestion of a monopoly in the DBaaS space seems to preclude the existence of other databases… Or am I misunderstanding?
I’m not sure what you mean by “IT is a business decision” — could you elaborate?
-edit- P.S. I’m trying to be supportive here; not trying to take anything away from what you’ve built with FerretDB! Honestly, there’s room for so room for innovation in this domain, and it’s nice to see new projects…
Re: FerretDB: open-source MongoDB alternative
#36Earlier quoted context omitted.
> They are still able to run cloud hosting just release their custom code? The SSPL license reads: > […] you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. > “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified…
No, the term “open source” was in use before long before the OSI, and it was in popular/hacker culture in the 1980s. UNIVAC used it in for a major system in the 1950s. [1] I used it in 1993 (I wrote a small BBS). The OSI looks and sounds like an authority on open source software, but their entire strategy is legal, political and quasi-philosophical. I get how easy it is to be mislead by them though — they’re good at…
There are 3 "competing" Open Source and Free Software definitions - from OSI, Free Software Foundation and Debian. MongoDB does not match any of them and most importantly does not match the spirit of Open Source Software Movement.
Re: FerretDB: open-source MongoDB alternative
#37Earlier quoted context omitted.
If there were JOINs it may be a sign MongoDB was not the best DB for you. It means the model was relational and a relational DB would be a better fit. MongoDB lookups are discouraged in general, and especially in analytical workloads, which cover a lot of data. MongoDB is better for the scenario, where all you need is already in the document.
It may also mean poor schema design. You can absolutely model relational data in MongoDB without relying on joins. If you want to normalize your data don't pick Mongo.
agreed, you can have reference fields to other collections and filter by them or query related data. But I wouldn't say its designed for relational workloads. Similarly I wouldn't use MongoDB for graph queries, even though it has an operator for just that.
Re: FerretDB: open-source MongoDB alternative
#38Earlier quoted context omitted.
It may also mean poor schema design. You can absolutely model relational data in MongoDB without relying on joins. If you want to normalize your data don't pick Mongo.
If you aren't normalizing, how are you ensuring that you don't avoid anomalies?
Not sure if this is exactly what you're referring to, but my understanding is that picking the "right" schema for a document database to ensure that you don't end up with slower queries like mentioned elsewhere in the thread tends to benefit from thinking at a somewhat lower level of granularity than you would probably need to with a relational database. Instead of just identifying "one to one", "one to many", "many to many", it's useful to ask questions like "how 'many' is many"; as a simple example, if the "many" in "one to many" is on the order of 10, maybe it makes sense to embed them in an array rather than use a separate collection for them. It can also help to start from thinking about the types of queries you might want and then designing the schema based on them rather than starting by deciding on the schema and then having the queries be based on that; if you're going to want certain data to be accessed at the same time, you're probably going to find some way to store it together.
Re: FerretDB: open-source MongoDB alternative
#39One thing that I didn't see discussed was why FerretDB uses Postgres as a backend and not a storage engine. Perhaps I am just missing something though.
Because PostgreSQL Is fantastic Open Source database engine, very popular with a lot of operational experience and tooling support. This is Open Source way of doing things - having project focus on as narrow problem as possible (first) and leverage as much of existing componets as possible.
Ok, that makes sense. I guess this project is targeting a compatible frontend for multiple backends. When I saw MongoDB alternative, I thought they were building both sides of the coin.
Re: FerretDB: open-source MongoDB alternative
#40Another day on the orange site where people don't understand that you can 100% have relationships in a NoSQL database - just don't try to do it the same way you do in a "relational" one or you're going to have a bad time. Storing everything in one collection is critical.
Here is an example using multi key indexes with Rick Houlihan from re:Invent 2022: https://youtu.be/eEENrNKxCdw?t=1131