Fucking mongo, fucking nested documents in nested documents that need to be filtered. I'm either really fucking dumb, the query is hard or both.

Nested documents are always a bad idea.

Also fucking hate MongoDB so much. No fucking idea why people choose MongoDB when postgres is better for 99% of use cases.

MongoDB should only be used when business logic is well understood. If you are having trouble with aggregation, probably should go with postgres?

An intro to dynamoDB and correct use cases for noSQL
https://youtu.be/HaEPXoXVf2k

It is a layer 8 problem honestly

I have never seen mongodb be a technical fit as the main/general database for a larger solution. I can envision scenarios where it's a better choice for specific data within an application, but at that point you may as well just make a table with a json column in your existing db.

I have had good experiences with mongodb when eventual consistency is ok and we have a ton of r/w to the same "table", but the tradeoffs always bit us in the ass in a people-want-off-the-project kinda way.

Deep objects was one of them. It only takes that one change by someone who doesn't know it's a bad idea, and reversing it after it's released is a much bigger task than implementering it.

Honorable mention to how you can try to enforce a schema, but one day you suddenly have half your _ids as objectid and the other half as guid, either in binary or string. Try to explain to whatever management why you need to put everything on hold despite things working fine in order to fix it or this will be a permanent time sink to manage.

I think MongoDB is awesome, it fits brilliantly with domain driven design as a document is analogous to an aggregate.
You do have to take on responsibility for not breaking your schema/dealing with backwards compatibility it that’s not been a huge deal.
My team are regretting using sql for some of our services as it doesn’t offer any advantages for us at all.

@TrevorTheRat

Balance is the key.

NoSQL means a lot of responsibility, monitoring and planning.

SQL is pretty much the same.

we used mongodb to receive vehicle positions, stuff that generated a high volume of data. anything else when to SQL. it worked pretty neatly.

NoSQL has its pros and cons, so does SQL, it's about knowing what better suits your needs.

This is what happens when you have a team who thinks every persistence requirement should be solved with mongo.