12 ms·

FerretDB: open-source MongoDB alternative

254 points by yawnxyz 4y ago

singeezie 4y ago
if ferretDB truly does provides ad-hoc queries, indexing, aggregation, and real-time data processing, making it well-suited for a wide range of applications, then sure , it’s a great alternative . I can see all types of web apps even enterprise systems working well w it.
- peterfarkas 4y ago
  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 set, either. [1]: https://github.com/orgs/FerretDB/projects/2/views/1 https://github.com/orgs/FerretDB/projects/2/views/1
  - jzelinskie 4y ago
    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?
    - aleksi 4y ago
      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 https://github.com/FerretDB/github-actions We are planning to do more there, open source the other part, and then blog about it.
quasilyte 4y ago
Congrats with v1.0! I remember the times when it was called MangoDB. :D
- aleksi 4y ago
  Yeah, those were easier times for sure :)
manishsharan 4y ago
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 .
- richieartoul 4y ago
  Tigris(https://github.com/tigrisdata/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
deepsun 4y ago
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 prefer). Turned out that was much faster to run analytical queries :) "document" is just row "collection" is just table
- phendrenad2 4y ago
  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.
  - deepsun 4y ago
    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.
- skatanski 4y ago
  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.
  - mgfist 4y ago
    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.
    - 4y ago
that_guy_iain 4y ago
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.
- peterfarkas 4y ago
  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-license/ https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
  - that_guy_iain 4y ago
    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.
    - aleksi 4y ago
      > 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.opensource.org/docs/history.php https://web.archive.org/web/20021001164015/http://www.openso... I think they are in a position to define what it means.
deleted 4y ago
[deleted]
jchannon 4y ago
If it can run a replica set on an apple m1 which mongo can’t currently do then great!
- vrtx0 4y ago
  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!
  - hartator 4y ago
    Can you send me an email? Julien at/ serpapi.com
dang 4y ago
Related: FerretDB 1.0 GA: open-source MongoDB alternative built on Postgres - https://news.ycombinator.com/item?id=35524235 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 https://news.ycombinator.com/item?id=29448906 - Dec 2021 (110 comments) MangoDB has a new name - https://news.ycombinator.com/item?id=29407987 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 https://news.ycombinator.com/item?id=29096331 - Nov 2021 (2 comments) MangoDB: An open-source MongoDB alternative - https://news.ycombinator.com/item?id=29071623 https://news.ycombinator.com/item?id=29071623 - Nov 2021 (200 comments) Show HN: MangoDB - https://news.ycombinator.com/item?id=4139723 https://news.ycombinator.com/item?id=4139723 - June 2012 (2 comments)
- yawnxyz 4y ago
  Kind of cool that MangoDB started out as a joke and ended up as a real, solid project
tristan957 4y ago
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.
- PeterZaitsev 4y ago
  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.
  - tristan957 4y ago
    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.
  - rmangi 4y ago
    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.
    - themerone 4y ago
      Just a few of the things you need to build if you don't do it this way. 1. A storage layer, 2. A network protocol with clients and servers, 3. A replication system, 4. an authentication system. 5. Administrative tools. If you roll everything yourself, you pretty much have to reinvent everything PostGres has except the SQL and relational aspects.
josevalerio 4y ago
Another 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 https://youtu.be/eEENrNKxCdw?t=1131
kbd 4y ago
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?
- peterfarkas 4y ago
  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/ https://blog.ferretdb.io/pjson-how-to-store-bson-in-jsonb/
  - Zababa 4y ago
    I'm curious about what makes document databases a good fit for e-commerce. I've never worked in that industry.
    - tylerchurch 4y ago
      Two things off the top of my head: 1. Denormalized data is often a boon. One of your key use cases is "give me all the information about this Product so I can show it to the user." Forget joining a ton of tables, just do 1 read of 1 product and go on your way. 2. A certain amount of more freeform data is expected. Different product categories will have different sets of information. T-shirts and drinkware both have sizes, but these sizes have nothing to do with each other. You can model all this in a traditional SQL database, but you have to stop and think really hard about it, and potentially end up with a plethora of tables. In a document database, it's much easier to just add the data and go on your way.
brightball 4y ago
I’m still waiting for the NoSQL crowd to realize that the best use case was always handled by CouchDB.
- yawnxyz 4y ago
  I started picking up CouchDB and PouchDB and the DX is fantastic. Always wondered why there’s never been any hype or more examples around this stack?
  - brightball 4y ago
    Mongo got popular at the same time and people cared more about top end benchmarks than anything else.
- yawnxyz 4y ago
  Apparently npm runs couchdb under the hood. There’s your answer to the “does it scale” question
vorticalbox 4y ago
Does ferret support transactions and document write locking?
- peterfarkas 4y ago
  Our development roadmap [1] is based on the needs of the users and the software we are focusing on building compatibility with. Interestingly, transactions are not commonly used and therefore it is not high on our priority list, it may take months until we get to it. Nevertheless, if enough users would request it, we would reconsider. The same goes for any other item on the roadmap, please check it out. [1]: https://github.com/orgs/FerretDB/projects/2 https://github.com/orgs/FerretDB/projects/2
ahachete 4y ago
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 performance of analytical queries by several orders of magnitude (that was "ToroDB Stampede"). ToroDB ended up being discontinued. Timing was not right. At the time, NoSQL was exploding, and users "didn't want to look back to SQL" --until they learned the notable advantages, but it was a time consuming and hard job. Today, there's a much higher acceptance of SQL and most recognize that data querying in many cases goes through, or is significantly helped, by SQL. I wish FerretDB a successful road and reach to where ToroDB didn't reach at the time. Good luck and congratulations on the 1.0 launch! [1]: https://torodb.com https://torodb.com
- nacs 4y ago
  Looks like they mentioned your DB in a (probably SEO-bait) blog post here: https://blog.ferretdb.io/5-database-alternatives-mongodb-2023/#notable-mention-torodb https://blog.ferretdb.io/5-database-alternatives-mongodb-202...
  - peterfarkas 4y ago
    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!
- satvikpendem 4y ago
  As well, Postgres now has great support for jsonb and querying that data, so you can effectively use Postgres as if it were NoSQL, if you really wanted to.
audioheavy 4y ago
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 lifting. To fully disclose, I have a biased view on this given that I work for a (closed source) serverless, no-ops DB provider (Fauna) that implements a distributed transaction engine that is natively document-relational and doesn't compromise on relational (ACID, transactional) guarantees. Although not directly comparable to an OSS DB, The market expects software and services to abstract as much complexity as possible. It is hard to imagine how such a Mongo/Postgres hybrid could handle hyper-scale apps that require highly consistent distributed writes.
- peterfarkas 4y ago
  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-amazon-eks-a-mongodb-api-to-distributed-sql-at-scale-1o2c https://dev.to/aws-heroes/ferretdb-yugabytedb-on-kubernetes-... https://dzone.com/articles/migrating-mongodb-collections-to-cockroachdb-with https://dzone.com/articles/migrating-mongodb-collections-to-... https://dzone.com/articles/using-cockroachdb-as-a-backend-for-oss-mongodb-alt https://dzone.com/articles/using-cockroachdb-as-a-backend-fo... https://dzone.com/articles/experimenting-with-unique-constraints-in-cockroach https://dzone.com/articles/experimenting-with-unique-constra... https://dzone.com/articles/cockroachdb-multiregion-abstractions-for-mongodb-d https://dzone.com/articles/cockroachdb-multiregion-abstracti...
chunsj 4y ago
I don’t think it is that matter whether a license is OSI compliant or not. The more important one is whether it is a Free Software License compliant like GPL3 preferably.
- bitwize 4y ago
  Sigh. Again. "Free software" is not coterminous with copyleft. It includes copyleft and non copyleft free licenses like BSD. Even Stallman would happily call BSD- or MIT-licensed stuff free software. The OSD was carefully chosen to incorporate what was already known as free software.
djha-skin 4y ago
When MongoDB came out it was sort of the anti-SQL database, so it is interesting that this flavor of the same kind of database is backed by postgreSQL.
0xbadcafebee 4y ago
But is it web scale?
coding123 4y ago
How compatible is it, supposedly the mongo drivers can connect to it. Can you connect spark mongo connector to it?
hartator 4y ago
Any benchmarks against regular MongoDB?
effnorwood 4y ago
[dead]
mathattack 4y ago
Probably a huge cost savings to turn off Al those MongoDB nodes.
exabrial 4y ago
Somewhere there's an actual implementation that copies everything to /dev/null, with the justification that if you're using mongodb, you probably don't care about your data anyway. Can't seem to find it.
- aleksi 4y ago
  I think you mean https://github.com/dcramer/mangodb https://github.com/dcramer/mangodb

254 points by yawnxyz 4y ago

if ferretDB truly does provides ad-hoc queries, indexing, aggregation, and real-time data processing, making it well-suited for a wide range of applications, then sure , it’s a great alternative . I can see all types of web apps even enterprise systems working well w it.

peterfarkas 4y ago
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 set, either. [1]: https://github.com/orgs/FerretDB/projects/2/views/1 https://github.com/orgs/FerretDB/projects/2/views/1
- jzelinskie 4y ago
  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?
  - aleksi 4y ago
    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 https://github.com/FerretDB/github-actions We are planning to do more there, open source the other part, and then blog about it.

quasilyte 4y ago

Congrats with v1.0! I remember the times when it was called MangoDB. :D

aleksi 4y ago
Yeah, those were easier times for sure :)

manishsharan 4y ago

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 .

richieartoul 4y ago
Tigris(https://github.com/tigrisdata/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

deepsun 4y ago

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 prefer). Turned out that was much faster to run analytical queries :) "document" is just row "collection" is just table

phendrenad2 4y ago
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.
- deepsun 4y ago
  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.
skatanski 4y ago
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.
- mgfist 4y ago
  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.
  - 4y ago

that_guy_iain 4y ago

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.

peterfarkas 4y ago
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-license/ https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
- that_guy_iain 4y ago
  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.
  - aleksi 4y ago
    > 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.opensource.org/docs/history.php https://web.archive.org/web/20021001164015/http://www.openso... I think they are in a position to define what it means.

deleted 4y ago

[deleted]

jchannon 4y ago

If it can run a replica set on an apple m1 which mongo can’t currently do then great!

vrtx0 4y ago
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!
- hartator 4y ago
  Can you send me an email? Julien at/ serpapi.com

dang 4y ago

Related: FerretDB 1.0 GA: open-source MongoDB alternative built on Postgres - https://news.ycombinator.com/item?id=35524235 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 https://news.ycombinator.com/item?id=29448906 - Dec 2021 (110 comments) MangoDB has a new name - https://news.ycombinator.com/item?id=29407987 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 https://news.ycombinator.com/item?id=29096331 - Nov 2021 (2 comments) MangoDB: An open-source MongoDB alternative - https://news.ycombinator.com/item?id=29071623 https://news.ycombinator.com/item?id=29071623 - Nov 2021 (200 comments) Show HN: MangoDB - https://news.ycombinator.com/item?id=4139723 https://news.ycombinator.com/item?id=4139723 - June 2012 (2 comments)

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

tristan957 4y ago

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.

PeterZaitsev 4y ago
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.
- tristan957 4y ago
  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.
- rmangi 4y ago
  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.
  - themerone 4y ago
    Just a few of the things you need to build if you don't do it this way. 1. A storage layer, 2. A network protocol with clients and servers, 3. A replication system, 4. an authentication system. 5. Administrative tools. If you roll everything yourself, you pretty much have to reinvent everything PostGres has except the SQL and relational aspects.

josevalerio 4y ago

Another 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 https://youtu.be/eEENrNKxCdw?t=1131

kbd 4y ago

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?

peterfarkas 4y ago
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/ https://blog.ferretdb.io/pjson-how-to-store-bson-in-jsonb/
- Zababa 4y ago
  I'm curious about what makes document databases a good fit for e-commerce. I've never worked in that industry.
  - tylerchurch 4y ago
    Two things off the top of my head: 1. Denormalized data is often a boon. One of your key use cases is "give me all the information about this Product so I can show it to the user." Forget joining a ton of tables, just do 1 read of 1 product and go on your way. 2. A certain amount of more freeform data is expected. Different product categories will have different sets of information. T-shirts and drinkware both have sizes, but these sizes have nothing to do with each other. You can model all this in a traditional SQL database, but you have to stop and think really hard about it, and potentially end up with a plethora of tables. In a document database, it's much easier to just add the data and go on your way.

brightball 4y ago

I’m still waiting for the NoSQL crowd to realize that the best use case was always handled by CouchDB.

yawnxyz 4y ago
I started picking up CouchDB and PouchDB and the DX is fantastic. Always wondered why there’s never been any hype or more examples around this stack?
- brightball 4y ago
  Mongo got popular at the same time and people cared more about top end benchmarks than anything else.
yawnxyz 4y ago
Apparently npm runs couchdb under the hood. There’s your answer to the “does it scale” question

vorticalbox 4y ago

Does ferret support transactions and document write locking?

peterfarkas 4y ago
Our development roadmap [1] is based on the needs of the users and the software we are focusing on building compatibility with. Interestingly, transactions are not commonly used and therefore it is not high on our priority list, it may take months until we get to it. Nevertheless, if enough users would request it, we would reconsider. The same goes for any other item on the roadmap, please check it out. [1]: https://github.com/orgs/FerretDB/projects/2 https://github.com/orgs/FerretDB/projects/2

ahachete 4y ago

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 performance of analytical queries by several orders of magnitude (that was "ToroDB Stampede"). ToroDB ended up being discontinued. Timing was not right. At the time, NoSQL was exploding, and users "didn't want to look back to SQL" --until they learned the notable advantages, but it was a time consuming and hard job. Today, there's a much higher acceptance of SQL and most recognize that data querying in many cases goes through, or is significantly helped, by SQL. I wish FerretDB a successful road and reach to where ToroDB didn't reach at the time. Good luck and congratulations on the 1.0 launch! [1]: https://torodb.com https://torodb.com

nacs 4y ago
Looks like they mentioned your DB in a (probably SEO-bait) blog post here: https://blog.ferretdb.io/5-database-alternatives-mongodb-2023/#notable-mention-torodb https://blog.ferretdb.io/5-database-alternatives-mongodb-202...
- peterfarkas 4y ago
  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!
satvikpendem 4y ago
As well, Postgres now has great support for jsonb and querying that data, so you can effectively use Postgres as if it were NoSQL, if you really wanted to.

audioheavy 4y ago

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 lifting. To fully disclose, I have a biased view on this given that I work for a (closed source) serverless, no-ops DB provider (Fauna) that implements a distributed transaction engine that is natively document-relational and doesn't compromise on relational (ACID, transactional) guarantees. Although not directly comparable to an OSS DB, The market expects software and services to abstract as much complexity as possible. It is hard to imagine how such a Mongo/Postgres hybrid could handle hyper-scale apps that require highly consistent distributed writes.

peterfarkas 4y ago
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-amazon-eks-a-mongodb-api-to-distributed-sql-at-scale-1o2c https://dev.to/aws-heroes/ferretdb-yugabytedb-on-kubernetes-... https://dzone.com/articles/migrating-mongodb-collections-to-cockroachdb-with https://dzone.com/articles/migrating-mongodb-collections-to-... https://dzone.com/articles/using-cockroachdb-as-a-backend-for-oss-mongodb-alt https://dzone.com/articles/using-cockroachdb-as-a-backend-fo... https://dzone.com/articles/experimenting-with-unique-constraints-in-cockroach https://dzone.com/articles/experimenting-with-unique-constra... https://dzone.com/articles/cockroachdb-multiregion-abstractions-for-mongodb-d https://dzone.com/articles/cockroachdb-multiregion-abstracti...

chunsj 4y ago

I don’t think it is that matter whether a license is OSI compliant or not. The more important one is whether it is a Free Software License compliant like GPL3 preferably.

bitwize 4y ago
Sigh. Again. "Free software" is not coterminous with copyleft. It includes copyleft and non copyleft free licenses like BSD. Even Stallman would happily call BSD- or MIT-licensed stuff free software. The OSD was carefully chosen to incorporate what was already known as free software.

djha-skin 4y ago

When MongoDB came out it was sort of the anti-SQL database, so it is interesting that this flavor of the same kind of database is backed by postgreSQL.

0xbadcafebee 4y ago

But is it web scale?

coding123 4y ago

How compatible is it, supposedly the mongo drivers can connect to it. Can you connect spark mongo connector to it?

hartator 4y ago

Any benchmarks against regular MongoDB?

effnorwood 4y ago

[dead]

mathattack 4y ago

Probably a huge cost savings to turn off Al those MongoDB nodes.

exabrial 4y ago

Somewhere there's an actual implementation that copies everything to /dev/null, with the justification that if you're using mongodb, you probably don't care about your data anyway. Can't seem to find it.

aleksi 4y ago
I think you mean https://github.com/dcramer/mangodb https://github.com/dcramer/mangodb