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

11–20 of 130 posts

Re: FerretDB: open-source MongoDB alternative

#11

Post by peterfarkas »

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

Re: FerretDB: open-source MongoDB alternative

#13

Post by skatanski »

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.

Re: FerretDB: open-source MongoDB alternative

#14

Post by packetlost »

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.

Re: FerretDB: open-source MongoDB alternative

#15

Post by phendrenad2 »

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…

MongoDB really only makes sense when you have an extremely large set of documents and you don't need to do this kind of statistics.

Re: FerretDB: open-source MongoDB alternative

#16

Post by dang »

Related:

FerretDB 1.0 GA: open-source MongoDB alternative built on Postgres - https://news.ycombinator.com/item?id=35524235 - April 2023 (2 comments)

FerretDB: A truly open-source MongoDB alternative - https://news.ycombinator.com/item?id=29448906 - Dec 2021 (110 comments)

MangoDB has a new name - https://news.ycombinator.com/item?id=29407987 - Dec 2021 (5 comments)

Open source MongoDB drop-in replacement, built on top of Postgres - https://news.ycombinator.com/item?id=29096331 - Nov 2021 (2 comments)

MangoDB: An open-source MongoDB alternative - https://news.ycombinator.com/item?id=29071623 - Nov 2021 (200 comments)

Show HN: MangoDB - https://news.ycombinator.com/item?id=4139723 - June 2012 (2 comments)

Re: FerretDB: open-source MongoDB alternative

#17

Post by that_guy_iain »

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…

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.

Re: FerretDB: open-source MongoDB alternative

#18

Post by aleksi »

jzelinskie wrote: post #10
peterfarkas wrote: post #4

Earlier quoted context omitted.

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

Congrats on the launch! Your GitHub Project board looks nice and clean. Do you have any posts or code for how your bot is managing issues there?

That’s easy, really. There was a person behind ferretdb-bot account – me. :) I still maintain our projects mostly manually.

That being said, we do have some automation in place. The public part is there: https://github.com/FerretDB/github-actions We are planning to do more there, open source the other part, and then blog about it.

Re: FerretDB: open-source MongoDB alternative

#19

Post by mgfist »

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.

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.

Re: FerretDB: open-source MongoDB alternative

#20

Post by softfalcon »

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…

I would recommend against modeling too many relations in a document DB. It can work, but it gets bogged down very quickly for the reasons you've stated.

My off-the-cuff suggestion is that document databases are not built to model normalized relational data. If you try to do so, you bring a whole new level of pain upon yourself. It is do-able, but it is hard and annoying.

I know this from extensive personal experience dealing with a large, highly relational Mongo database.

I am very glad you found a solution within Postgres that works for you, and your mapping of document to row and collection to table is very apt!

If possible, would you care to tell me what the size of said documents (rows) and collections (tables) are in your solution? I am curious if in another life, we might have built our tech stack on Postgres instead of MongoDB and been much happier for doing so.

Post reply on HN