Live data from Hacker News

FerretDB: open-source MongoDB alternative

blog.ferretdb.io

41–50 of 130 posts

Re: FerretDB: open-source MongoDB alternative

#41

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.

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.

Cramming an api for one product on top of another is absolutely not “the open source way” I’d expect a much better explanation for this Frankenstein’s monster. This seems like it would work but never scale.

Re: FerretDB: open-source MongoDB alternative

#42
Ok, old man yelling at clouds moment finally coming for me. Now that we've been through the document-database heyday and are out the other end, what have we learned about where document databases are a good fit?

At the time I looked at them like a fad. "These script kiddies want to write javascript and ignore schemas. Let's see how well that works out for them." As expected, most of what I ever hear is regret.

Today, MongoDB has grown out of the reliability issues it had in the past, and Postgres has json features for the occasional times it's useful to store some loosely structured data along with otherwise relational data. Question is, what applications is a document-first database good for, outside of prototyping?

Edit: and to make sure I understand, FerretDB is a layer reimplementing MongoDB on top of Postgres and its json features?

Re: FerretDB: open-source MongoDB alternative

#43
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…

Joins only make sense in analytical context as a tool to get some additional data into your report and almost never as domain modeling concept. People should pretty much hardly ever use RDBMS for their domain data... but since everyone learns RDBMS as their first DB, we have these horrible ORM frameworks on every corner.

Re: FerretDB: open-source MongoDB alternative

#45

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.

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…

I am not really sure what your issue is. What you think open-source as freemium isn’t a model?

If it wasn’t for copy-left licenses that forced companies to release code that they used to create their products we wouldn’t have Linux in its current state.

In a world, where many products are cloud based it seems fair and within the current model of open source to force code sharing.

Re: FerretDB: open-source MongoDB alternative

#46
post #29

Earlier quoted context omitted.

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.

Please state in what way they don’t? This is what I’m confused about. Apgl is open source but a sspl isn’t? They seem to be aimed at solving the same thing, which is cloud/server based code modifications.

Re: FerretDB: open-source MongoDB alternative

#47
post #23

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…

I am confused. If you use a custom storage system then you would have the code for it. No?

Re: FerretDB: open-source MongoDB alternative

#48
post #42

Ok, old man yelling at clouds moment finally coming for me. Now that we've been through the document-database heyday and are out the other end, what have we learned about where document databases are a good fit? At the time I looked at them like a fad. "These script kiddies want to write javascript and ignore schemas. Let's see how well that works out for them." As expected, most of what I ever hear is regret. Today,…

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/

Re: FerretDB: open-source MongoDB alternative

#49
post #42

Ok, old man yelling at clouds moment finally coming for me. Now that we've been through the document-database heyday and are out the other end, what have we learned about where document databases are a good fit? At the time I looked at them like a fad. "These script kiddies want to write javascript and ignore schemas. Let's see how well that works out for them." As expected, most of what I ever hear is regret. Today,…

A use case I have for FerretDB is migrating existing apps off MongoDB without needing to change the code. I find it funny that you could call these now „legacy“ apps.

Re: FerretDB: open-source MongoDB alternative

#50
post #49
post #42

Ok, old man yelling at clouds moment finally coming for me. Now that we've been through the document-database heyday and are out the other end, what have we learned about where document databases are a good fit? At the time I looked at them like a fad. "These script kiddies want to write javascript and ignore schemas. Let's see how well that works out for them." As expected, most of what I ever hear is regret. Today,…

A use case I have for FerretDB is migrating existing apps off MongoDB without needing to change the code. I find it funny that you could call these now „legacy“ apps.

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.

Post reply on HN