Been an SRE and DBA for almost 20 years and the only truth in tech I firmly believe in: use whatever you want in a new project. Build fast and get it out. Once you have paying users, hire old dads like me to move you to Cassandra or Vitess or TiDB or something, or dont and just pay the bills for mongodb and laugh all the way to Series C.

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.

We're seeing a convergence of document DBs adding relational features, and relational DBs adding document features. At this point I find the best of both worlds to simply be PG with JSONB.

    create table document (
      id uuid primary key default gen_random_uuid(),
      doc jsonb
    );

This alone will give you a huge number of the features that Mongo provides, but also the full power of Postgres for everything else.

Until very recently, at the company I work for, we were running one of the largest (if not the largest) replica set cluster in terms of number of documents stored (~20B) and data size ~11TB. The database held up nicely in the past 10 years since the very first inception of the product. We had to do some optimizations over the years, but those are expected with any database. Since Mongo Atlas has a hard limit on the maximum disk size of 14TB we explored multiple migration options - sharding Mongo or moving to Postgres/TimescaleDB or another time series database. During the evaluation of alternative database we couldn't find one which supported our use case, that's highly available, could scale horizontally and that's easily maintainable (e.g. upgrades on Mongo Atlas require no manual intervention and there's no downtime even when going to the next major version). We had to work around numerous bugs that we encountered during sharding that were specific to our workloads, but the migration was seamless and required ~1h of downtime (mainly required to fine-tune database parameters). We've had very few issues with it over the years. I think Mongo is a mature technology and it makes sense depending on the type of data you're storing. I know at least few other healthcare companies that are using it for storing life-critical data even at a larger scale.

Did you evaluate RavenDB? Just out of interest

Ravendb is trash. It can’t handle even 1/10 of this type of a load, it was trashed in jepsen testing too. I had to work with it 4 years and i disliked it.

Thanks! I am a little disappointed that it seems to be trash :(

> are there still good reasons for using it in a new project in 2025?

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

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.

Postgres defaults to preventing delete when foreign keys would be violated, not cascading.

The sane default. It was a Django project, and unfortunately many relations were set to ondelete=cascade.

My main concern would be with querying. What is querying like in modern mongodb, or scylladb? I've seen couchbase ads showing a superset of sql, etc. Last I recall Mongo had a weird query system.

Basically it requires you to write the query plan yourself, which IMO is not a bad idea for an OLTP system.

Cascading deletes are an optional feature in every DB that supports them, aren’t they? I only have DBA-ish experience with SQL Server, but there they are fully opt in.

Yes, because they are terrible and break replication for cross system repl.

Yeah, but OP made it seem like they were some kind of mandatory or at least default feature.

MongoDB is used for ~8 years straight here with a replica set that replicates itself and even crossing datacenter boundaries. It runs smooth, stable, fast and allows for a good backup strategy. It implements all the database concept you can image, offers great compression algos and it easy to maintain. Short: It drives the job and it does that good.

MongoDB as a company is growing 20% y/y and 2B in revenue.

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.

Interesting, can you elaborate on what you mean by (b) with an example?

They're really good at sales and marketing, especially aimed at beginners.

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.

What you're writing sounds like marketing to me. Really bad one...

Personal opinion.

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.

The original storage engine was terrible, but they wised up and later acquired and adopted WiredTiger as the default. It was sort of their InnoDB moment and went a long way to improving performance, reliability, replication, and other "enterprisey" features.

> Has it become a legacy product, or are there still good reasons for using it in a new project in 2025?

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

PostgreSQL does not have built-in clustering but Patroni does it automatically.

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.

If you rely on Postgres and/or Mysql replication then you'll need a DBA on call. Lots of manual work involved in babysitting them when stuff goes south.

Mongodb is entirely automatic, you just delete bad servers and reprovision them automatically and everything "just works" with no interruption.

mongodb is not open

I disagree with that. The Server Side Public License is more open than the AGPL.

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.

People have the most varied creeds and faiths. However the facts are that it doesn't respect freedom 0.

Freedom of what? Freedom of business for cloud providers? I don't give a shit about that.

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.

Agreed. It seems like something really bad is going on. I hope the Mongodb security team will handle it ASAP.

Only here you read that MongoDB is a legacy product.

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 didn't have replication integrated. Slony replication existed for 20 years, same as pgpool.

I doubt they use mongodb for the actual real time game. Probably just for the user accounts, items, skins and that sort of stuff. It could literally be done by anything else.

Did MongoDB have _proper_ replication 15 years ago?

> or are there still good reasons for using it in a new project in 2025

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/

a) Big data is more than just the size of the data. It's about how you treat that data i.e. instead of doing expensive and brittle up-front RDBMS modelling you instead dump it all into a data lake and figure out how to handle the data at run-time. And it is still the standard pattern in almost all companies today.

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

That's not how software works. In my experience using mongodb just means that now every single bug in the code creates messed up data for a few months/years and then when that data pops up the software crashes :D

I can assure you that Stripe does not regret the decision.

Interesting, a lot of ex stripe eng I talk to say the opposite, but that they made it work.

it's probably stable enough... but our teams got like 90% reduction in their bills by moving off mongodb atlas to postgres. of course, architect your data schema right and you'll have much more flexibility in choosing a database engine that can be fast, cheap, and easy to operate.