Why would you say duped? Is there some major problem with mongoDB? The way you've stated this makes it sound like there's some common knowledge I should be aware of.

> Is there some major problem with mongoDB?

Yes, plenty. It's mostly useless for relational data.

Nowadays that's clear on the documentation and you won't get loud people proclaiming that it's useful there, but there was a time when both of those were false.

By relational data do you mean data that has no nesting or arrays? Or data that you always want to query with a join? Something else?

That that you would want to query with a join and have invariants that spread through those places you would want to join.

Just keeping invariants of any kind is already non-trivial and will probably break at some point in a long lived system.

I see so reference data that you want included in an object for which you're willing to pay the performance overhead of a join rather than denormalize across many object representions in your database. This model has some downsides when it comes to reasoning about scale and denormalization isn't necessarily a consistency quagmire when you can use transactions to keep multiple objects in sync. More generally you can absolutely do this types of queries in modern data systems whether or not they are "relational".

Yeah, I guess I should retract my claim that people aren't claiming it's useful for relational data anymore.

Anyway, I was focusing on invariants. But yes, destroying your performance every time you need an atomic change or joining values also makes it bad for relational data.

That doesn't mean it's useless, just that it should not be used on the most common problem people have with their data.

Postgres literally beats MongoDB at JSON in benchmarks. Y'know, the thing that's supposed to be Mongo's bread and butter?

Mongodb was a lot easier to manipulate json in for a while vs postgres, but once postgres got json path support it evened out a bit imo.

Say you have some json and nested in it somewhere is an array of objects, and you want to just map over that and update those objects. I was writing a migration to do that in Postgres <11 once and it was not fun to try and figure out how to do it.

I haven't worked with Mongo in years though, so no clue how it has evolved since like 2015.

Which benchmark is that?

Unfortunately that benchmark was very inaccurate. They tuned the postgres configuration and didn't tune MongoDB. They also used an unsupported, experimental driver without connection pooling on MongoDB.

For example: they measured Query B execution time on postgres: 41m3s, mongodb: 1h13m3s. When MongoDB measured Query B with a supported driver, the execution time was only 3m30s more than 10x faster than postgres!

You'll find details here: https://www.mongodb.com/blog/post/benchmarking-do-it-right-o...

Thanks for that info. Statistics, misunderstandings, lies, benchmarks, database benchmarks...