Genuinely interested: what problems does mongo fit better than mainstream competitors these days? Why would you use it on a new project?

My application's primary task is to move JSON objects between storage and front-end. It does a lot more, but that's it's primary task. So document storage is a logical choice. There are no real reasons to join records, although it sometimes is more efficient to do so. MongoDB's join operation has one advantage (for 1:N relations): it groups the joined records as an array in the document, instead of multiplying the answers, so whatever function operates on the original data, also works on the joined data. The data itself is hierarchical in nature, so back-end operations also preferably work on structured data instead of rows.

You can argue that you can imitate that in Postgres or even SQLite by storing in JSON fields, but there are things they can't do quite as efficiently (e.g. indexing array contents); storage itself isn't very efficient either. But ignoring that, there's no functional difference: it's document in, document out. So then the choice boils down to speed, memory usage, etc. One day I'm going to check if Postgresql offers a real performance advantage, but given the backlog, that may take a while. Until then, MongoDB just works.

To be honest, I don't think it was a stand-out 'it's better for X than Y because of Z' kind of choice for us. We are a bank, and so database options are quite limited (it's Oracle or Mongo, essentially for certain applications).

I have one application at the moment which needs to handle about 175k writes/second across AZ's. We are not sharding at the moment, but probably will once scale requires (we are getting close) -- so just one big replica-set and it's behaving .. really nicely. I tried to emulate this workload on Postgres (which is my favourite database over my entire career so far (many scars)) and we couldn't get it to where mongo was for this workload, multi-az is painful, automatic failover is still an unanswered question really, I've tried all the 'right around the corner' multi-master Postgres options and none of them did anything other than make us sad.

From the developer standpoint, it's very nice to use, I just throw documents at it and it saves them. If I want an extra field, I just add it. If I want an index on something, also just add it. No big complicated schema migrations.

Especially what helps is we have absolutely incredibly great support from MongoDB. We have a _weekly_ call with them with a bunch of their senior engineers who answer all our stupid questions and proactively look for things to improve.

Ops story is also good, we aren't using Atlas, but the on-prem kube setup while a bit clunky has enough CRDs and whatever to keep devops happy for weeks at a time.

tl;dr -- it's boring and predictable, and I rarely have to think about it which is all I ever want from a database. I'm sure we could achieve the same results with other database technologies, but the ROI on even investigating them would not be worth it, as at best I think we would end up at the same place we are at now. People seem to have deeply religious feelings on databases, but I've never really been one of them.

I would not hesitate to use it on a new project.