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

71–80 of 130 posts

Re: FerretDB: open-source MongoDB alternative

#71

Post by peterfarkas »

nacs wrote: post #69
ahachete wrote: post #62

I applaud this effort. Many years ago I founded a project called ToroDB [1]. ToroDB had a vision very similar to that of FerretDB's: help MongoDB users feel at home on Postgres. This has far reaching implications, like allowing MongoDB applications to run without MongoDB (this is what FerretDB is essentially and what "ToroDB Server" was meant to be) or to replicate data from MongoDB to Postgres to improve the perform…

Looks like they mentioned your DB in a (probably SEO-bait) blog post here: https://blog.ferretdb.io/5-database-alternatives-mongodb-202...

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!

Re: FerretDB: open-source MongoDB alternative

#72

Post by peterfarkas »

audioheavy wrote: post #67

This sounds like an interesting hybrid implementation, and I understand its motivation. However, if distributed writes at low latency with the highest consistency guarantees are essential, combining those two layers (Mongo and PostgreSQL) isn't worth the complexity. It looks like you can administer it with both Mongo and PostgreSQL tools, but do you want to? Clusters, partitioning, replication? That's a lot of heavy…

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

Re: FerretDB: open-source MongoDB alternative

#73

Post by yawnxyz »

dang wrote: post #16

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

Kind of cool that MangoDB started out as a joke and ended up as a real, solid project

Re: FerretDB: open-source MongoDB alternative

#74

Post by unusualmonkey »

tasubotadas wrote: post #43
softfalcon wrote: post #20

Earlier quoted context omitted.

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.

Curious why you think this? I've found Relational databases pretty powerful, and learned mongo first.

Re: FerretDB: open-source MongoDB alternative

#75

Post by deepsun »

softfalcon wrote: post #20
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…

We had everything de-normalized, as you pointed out.

However, every now and then we had some one-off questions that required using Mongo for something it's not designed for. However, migrating to postgres+JSONB made it easy to do both.

Re: FerretDB: open-source MongoDB alternative

#76

Post by yawnxyz »

peterfarkas wrote: post #48
kbd wrote: 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-co…

if we use Ferret for prototyping and eventually land on a schema, would it be possible to convert the FerretDB rows into more structured postgres? Would be so cool if it could just analyze and create a schema for you, you double check it, and it just works.

I think being able to convert back and forth would make it so worthwhile!

Re: FerretDB: open-source MongoDB alternative

#77

Post by deepsun »

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.

No, our app didn't use JOINs for the main work. But, as I wrote, every now and then we had some one-off requests that required either JOIN or GROUP BY or both.

With postgres+JSONB we could do both at the same time on live data.

Re: FerretDB: open-source MongoDB alternative

#78

Post by deepsun »

forgetfulness wrote: post #25
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.

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

Same thoughts. I see mongo as a key-value store (string key -> string value), with a json wrapper over the values.

Re: FerretDB: open-source MongoDB alternative

#79

Post by deepsun »

phendrenad2 wrote: post #15
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.

Yep, although for large datasets I'd prefer multi-master architecture, depending what is needed, for example Blob storages or Cassandra for key-value, and BigQuery or Clickhouse for analytics.

We also thought we wouldn't need it, but turned out sometimes we wanted to run some stats.

Re: FerretDB: open-source MongoDB alternative

#80

Post by ocdtrekkie »

mitjam wrote: post #49
kbd wrote: 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.

Yeah, anxiously waiting for FerretDB to support Meteor over here.
Post reply on HN