Compare this Jepsen analysis with that of MongoDB 2.4.3 from 2013[1] and you'll see that MongoDB has come a long, long way in the last few years. Note that the linked report on 3.6.4 was actually funded by MongoDB. I think a lot of the hate in the past was caused by their marketing writing checks that the technology couldn't cash. I think that has changed somewhat, but I'm not sure whether popular opinion has come around.
It's actually a completely different database between version 2 and 3.
They acquired WiredTiger in 2014 and MongoDB has never looked back since. Sure there is a lot of hate on HN but they are doing very well out in the real world. And actually it's a pretty good database if your domain model fits.
I agree. Their marketing was way ahead of their technology and that caught up to them. That being said, they’ve been rapidly improving the tech and it’s looking like a really solid option now.
That's still in the limited uses that not having proper SQL semantics allows.
I've had to deal with a key-valued-json database on another technology. Lots of different json shapes, even when they are supposed to represent the same concept. Every new feature bringing its own tweak.
Low performance, as ad hoc materialized scans + hash joins had to have been developed in the app. I hated every second of it.
In the end, I came away with the following exhortation for people tempted to eat the easiness of MongoDB-likes:
The world is not a tree. It is a graph. Each entity in the database exists in real life, and interacts with others freely each in a specific manner. This is why they cannot be represented as trees (which is what json is). You need a graph, types, constraint checks, and acid semantics; and boring postgres tables + SQL will provide that.
Sure trees are a great way to represent and transport a piece of state. It is self-contained and succinct. This is why I'm a big advocate of GraphQL on top of an RDBMS. Out of the graph of properly stored entities, you can extract the tree that is relevant for the app view you're working with.
What's your opinion of ember and its sideloading semantics for JSON? I found it interesting... until I had to write my own REST endpoints. I found that none of the database tools I had available were up to doing it. Having to write all those sideloads by hand ended up being too tedious for a non-paying gig and I dropped the experiment.
1: https://aphyr.com/posts/284-call-me-maybe-mongodb