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/
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.
I think being able to convert back and forth would make it so worthwhile!
What's the alternative you want to move to?
The biggest issue right now is that MongoDB compares and sorts values differently than PostgreSQL/jsonb. For that reason, we have to do a lot of filtering on the FerretDB side, and that can't be great for performance. Pushing more work on the database size should make FerretDB perform much better.
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.
Would you mind sharing the specific Meteor app you are looking to get supported?
MeteorJS is among the most requested applications/frameworks our users are looking to use with FerretDB.
[1]: https://twitter.com/CowboyCaramel/status/1646089964126347264
One of the issues we hit is here: https://github.com/meteor/meteor/issues/11666 in which if you happened to have a Mongo database over eight years old, you needed manual intervention to correct it, even if you had done intermediate version updates in between.
Meteor patched around this issue... but after dropping support for several releases of Mongo. So we essentially need to build our own automation which understands and can export old Mongo databases, and then import new Mongo databases, while shipping a Meteor app that can only run on one or the other, which has to auto-update smoothly, and recover from failure like if there isn't hard drive space to handle the process.
And then we also need to implement that within app sandboxes which can also arbitrarily terminate so that also has to recover well and we need to ship the logic to do this with every Mongo-backed app package until the end of time.
Understanding the advantages and shortfalls is sometimes harder too. Mongo having multiple secondary indexes is pretty nice as well. Haven't dug into FerretDB, my first question is if it will run over the top of CockroachDB, as that's how I would probably want it configured. Then, I'm not sure if I wouldn't just use the JSONB surface in PostgreSQL/CockroachDB directly.
I think it just really depends on how/what you need to accomplish.
Some criteria I’d use: * Data is already naturally segregated and won’t be shared/joined much during normal usage * App already has transactions modeled in the application layer (or I guess if consistency really doesn’t matter) * App would benefit from being geographically distributed. * App is written in a language with a strong type system, has high code quality, test coverage, etc.
In my case, my company makes a distributed project management application. All changes to projects are canonically ordered and applied in the application layer.
Data is stored in Cloudflare Durable Objects and R2. Hard to classify DOs but they’re a lot closer to a document store than an SQL Db.
There are some nice benefits that would be hard to replicate with a traditional SQL Db setup.
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?