Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FerretDB: open-source MongoDB alternative

blog.ferretdb.io

Post reply on HN
Print view View original

21–30 of 130 posts

Re: FerretDB: open-source MongoDB alternative

#21

Post by aleksi »

packetlost wrote: post #14
deepsun wrote: post #7

At one company we had one-off requests to run get some statistics from our mongodb. Writing the proper queries proven pretty tricky whenever GROUP BY/JOINs were involved, so I used online converters between SQL -> mongo query. But then I realized that PostgreSQL has nice JSONB type (supports indices for subfields). So I put all the mongo data into tables with a single JSONB column (or two columns id+data, if you pref…

The only problem I have with PostgreSQL's JSONB type is it strictly implements the JSON standard, so things like nulls and integers aren't supported. Depending on your data, this could be a real problem.

FWIW, JSONB supports JSON nulls, and all numbers are encoded as `numeric` type, storing integers and float64 values precisely (well, as much as possible for float64 values).

But you comment is correct for other data types like date-times and binary strings where some form of encoding/decoding is needed.

Re: FerretDB: open-source MongoDB alternative

#22

Post by udp »

packetlost wrote: post #14
deepsun wrote: post #7

At one company we had one-off requests to run get some statistics from our mongodb. Writing the proper queries proven pretty tricky whenever GROUP BY/JOINs were involved, so I used online converters between SQL -> mongo query. But then I realized that PostgreSQL has nice JSONB type (supports indices for subfields). So I put all the mongo data into tables with a single JSONB column (or two columns id+data, if you pref…

The only problem I have with PostgreSQL's JSONB type is it strictly implements the JSON standard, so things like nulls and integers aren't supported. Depending on your data, this could be a real problem.

The json standard has nulls

Re: FerretDB: open-source MongoDB alternative

#23

Post by aleksi »

that_guy_iain wrote: post #17
peterfarkas wrote: post #11

Earlier 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…

Personally, that blog post is just arrogance from OSI. I read it. It didn’t make clear which freedoms were being removed. They are still able to run cloud hosting just release their custom code? And OSI thinking they alone get to decide what is and what is not open source is arrogant.

> 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 version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

You just can't comply with those terms if you don't have access to the source code of your storage software, for example.

(but I'm not a lawyer, of course)

> And OSI thinking they alone get to decide what is and what is not open source is arrogant.

OSI invented the term “open source”: https://web.archive.org/web/20021001164015/http://www.openso... I think they are in a position to define what it means.

Re: FerretDB: open-source MongoDB alternative

#24

Post by peterfarkas »

that_guy_iain wrote: post #17
peterfarkas wrote: post #11

Earlier 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…

Personally, that blog post is just arrogance from OSI. I read it. It didn’t make clear which freedoms were being removed. They are still able to run cloud hosting just release their custom code? And OSI thinking they alone get to decide what is and what is not open source is arrogant.

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...

Re: FerretDB: open-source MongoDB alternative

#25

Post by forgetfulness »

skatanski wrote: post #13
deepsun wrote: post #7

At one company we had one-off requests to run get some statistics from our mongodb. Writing the proper queries proven pretty tricky whenever GROUP BY/JOINs were involved, so I used online converters between SQL -> mongo query. But then I realized that PostgreSQL has nice JSONB type (supports indices for subfields). So I put all the mongo data into tables with a single JSONB column (or two columns id+data, if you pref…

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.

Should it be used as a database in the way that Postgres would be used as a database? It seems pretty unfit for that role, with its past durability issues and that writes have to be tailored to how the data will be consumed, due to lack of ad-hoc queries.

As something layered on top of the actual source of truth it may be reasonable, writing a materialized version of a costly query that's read very often, sure, but that's an optimization and it'd be competing with Redis for what matters there.

Re: FerretDB: open-source MongoDB alternative

#26

Post by richieartoul »

manishsharan wrote: post #6

This looks great. I had been using Document Layer for FoundationDB but Apple has abandoned the Document Layer for the FoundationDB ; so this looks promising .

Tigris(https://github.com/tigrisdata/tigris) is one of the supported FerretDB backends and Tigris is backed by FoundationDB, so you can still have the Mongo interface with the reliability and scaling of FDB if that's what you're looking for

Re: FerretDB: open-source MongoDB alternative

#27

Post by eropple »

mgfist wrote: post #19
skatanski wrote: post #13

Earlier 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.

If you aren't normalizing, how are you ensuring that you don't avoid anomalies?

Re: FerretDB: open-source MongoDB alternative

#28

Post by vrtx0 »

peterfarkas wrote: post #11
that_guy_iain wrote: post #8

I’m confused, to me it seems that MongoDB is also open-source. Their new license is basically just a better agpl. I only point this out because the blog post makes a point of saying it’s not open source.

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 do so, right?

Furthermore, if you’re using MongoDB, be it self-hosted, with a vendor, or even some proprietary database that implements the wire protocol for compatibility, you’re likely using MongoDB-developed clients/drivers, which are Apache 2.0 (“OSI-approved open source”).

So it seems like the only way to be locked into a vendor is if you’re using MongoDB drivers to connect with a 3rd party database that doesn’t fully implement all functionality of MongoDB in a compatible way… Right?

I could be wrong, but as someone who contributed to MongoDB as an open source project, and was later hired by MongoDB based on said contributions, it kinda hurts to see the OSI’s “MongoDB isn’t open source anymore” campaign work so well.

That said, I sincerely wish the team behind this project all the best!

My complaints aren’t against anyone in the open source communities I’ve known and loved. Just this self-important legal organization that acts like it controls (and even gets to define) open source software.

P.S. I left MongoDB in 2015 due to a neurological disability, but it was one of the highlights of my career, with so many kind and brilliant people. But it’s also been a while, and my brain doesn’t work so well these days, so please correct me if I got anything wrong!

Re: FerretDB: open-source MongoDB alternative

#29

Post by vrtx0 »

aleksi wrote: post #23
that_guy_iain wrote: post #17

Earlier quoted context omitted.

Personally, that blog post is just arrogance from OSI. I read it. It didn’t make clear which freedoms were being removed. They are still able to run cloud hosting just release their custom code? And OSI thinking they alone get to decide what is and what is not open source is arrogant.

> 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 spinning things and rewriting history.

https://en.m.wikipedia.org/wiki/History_of_free_and_open-sou...

Re: FerretDB: open-source MongoDB alternative

#30

Post by PeterZaitsev »

vrtx0 wrote: post #28
peterfarkas wrote: post #11

Earlier 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…

"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 it is created for cooperation and innovation together, not monopoly.

Post reply on HN