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.
