Comment by cyberpunk
11 hours ago
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.
> 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.
This sentence summarize all the issues developers working with Mongo will have: multiple version of documents living in the same DB and unpredictable structure
Best thing MongoDB have it's definitely their marketing (making everyone think it's amazing to invest hundreds of millions to deliver an "OK" tier database) and their customer support
Eh, not really. I've done both at considerable scale, and I don't hit these problems. Perhaps you need better developers? For sure, having your database enforce guardrails on what $thing should look like means your code can be lower quality, but you should pick the right tool for the job. For scenarios where I have one 'thing' that's not very relational, it works well. If your application dies because your $thing expects some field which isn't there, that's a you problem not a storage problem.