[beckler]

I have to use mongo at work. They used it because they thought it would be easier for the developers, but I find the query pipelines confusing at best. It can be extremely nuanced depending on how complex your aggregations are. I usually have to rewrite complex queries often because there are so many subtle details that can make your queries return incorrect data.

Even the docs in mongo tell you what kind of SQL query certain operators perform… I would rather just do SQL.

[diveanon]

I have used mongo heavily in the past and had similar problems.

More often than not I hear the rationalization the no-sql is easier to develop because you don't need schemas. In my opinion that is a horrible anit-pattern.

What I am curious about is the use-cases where mongo actually is the correct choice of pg.

[cryptos]

The argument that a schemaless DB would be easier for developers is pretty much the same argument that a programming language with dynamic tpying would be easier than a language with static typing. That might be true in the short term, but just like static typing a schema helps in the long run. Types and schemas make explicit what would otherwise be implicit knowledge and help to catch bugs early.

[IceDane]

The problem is that people seem to focus on some tiny aspect that it might improve, like "how easy it is to deal with data of varying shape", ignoring the fact that by ignoring the problem, you aren't making it go away.

You always need to know what kind of data you are dealing with. If you use mongodb, you no longer have the database as the source of truth for the shape of your data, so you need to maintain this somewhere else, whether it be in mongoose models, in your API layer or just in your frontend. The point is that you aren't solving a problem as much as pushing it around, and usually pushing it around results in it being handled in the wrong place(like the frontend).