About 15 years ago or so, webscale was everything and MongoDB was webscale[1][2] hence being used everywhere.
Has it become a legacy product, or are there still good reasons for using it in a new project in 2025?
Has it become a legacy product, or are there still good reasons for using it in a new project in 2025?
I wouldn't start a new project with MongoDB, I'd probably use ScyllaDB, and i'd spent months getting the data model just right while you launch and get paying customers.
create table document (
id uuid primary key default gen_random_uuid(),
doc jsonb
);
I've written this before: if your data looks like trees, with some loose coupling between them, it's a good choice. And most data does look like trees.
It does place some extra duties on the backend. E.g., mongodb doesn't propagate ("cascade") deletes (this also happens to be a feature I dislike: not so long ago, a delete of an insignificant record triggered an avalanche of deletes in a postgresql database, and restoring that took quite a bit of time.)
I had an education statup a little while ago.
Courses had many cohorts, cohorts had many sessions.
It really was much nicer having a single tree structure for each course, appending new cohorts etc, rather than trying to represent this in a flat Postgres database.
That said I acknowledge and agree with other commenter's experiences about MongoDB and data loss in the past.
So very far from being a legacy product.
I still use it for new projects because (a) Atlas is genuinely a solid offering with a great price point for startups and (b) schema-less datastores have become more of a necessity as our control of data has decreased e.g. SaaS companies dictate their schema and we need to accomodate.
I'm still puzzled why people use it given that it's a database and there's nothing technical it ever did better than any of its competitors. The best that can be said for it is that it works about as well in some circumstances as competing databases do.
I swore away from it for 10 years, but came back recently. And I'm pleasantly surprised with the developer experience of MongoDB Atlas (the cloud version).
You just have to keep in mind the common sense best practices about developing with kv stores, and you'll be mostly alright.
We're in the process of migrating our legacy stuff to mongodb right now.
If you want a high-availability database solution that "just works" and is open then you don't have many other options.
(Postgress and Mysql don't have automatic failover and recovery.)
In the same sense that the GPL is more open than the MIT license; more viral requirements for openness are generally a good thing. I don't want Amazon and the ilk deploying hosted Mongodb clusters.
Open source for me is a hedge against risks. (Especially political and/or legal ones.) Mongodb's current license resolves that issue for me perfectly.
MySQL Group Replication isn‘t automatic in all cases, like starting after all nodes failed, and it has some limitations, but it is built-in.
Not saying that MongoDB ReplicaSet is bad, has been working very well for us AFAICT.
Mongodb is entirely automatic, you just delete bad servers and reprovision them automatically and everything "just works" with no interruption.
Fortnite runs on MongoDB, it's one of the largest game on the planet.
15 years ago Postgres did not have proper replication, shocking right?
it's not clear there ever was. Most of the big users I'm aware of, like Stripe, don't seem to have needed it and regretted the decision. Big data didn't become a thing in the way people expected[0]. If you really did need the scalability of Mongo you'd choose a NewSql database like TiDB[1].
[0] https://motherduck.com/blog/big-data-is-dead/ [1] https://docs.pingcap.com/
b) Nobody was choosing MongoDB solely for performance. If it was you would choose some in-memory K/V store. It was about it being the only well supported document store that was also fast and scalable.
c) Stripe’s DocDB is an extension of MongoDB Community: https://stripe.com/blog/how-stripes-document-databases-suppo...