The drawback of the key-value store is that the document design has to be modeled after the shape of its read requirements, which have to be determined up front, and querying outside of those read patterns is relatively limited; the tradeoff is flexibility for performance.

Imagine there are a bunch of other relational entities like `usergroups`, `permissions`, `organizations`, and then domain stuff like `articles`, `categories`, `tags`, and more, all off which have n-to-many relationships with each other. Now when I design my document, how do I decide which data is nested in which? With any given document structure, the application read and write patterns becomes centric to that data view at the cost of easily working with the data in other views.

So I turn to a relational DB for that flexibility because everything is normalized. But the drawback to relational DB's is the complexity involved with changing its schema: locks/downtime during table alterations, DDL source control. The fewer alterations the better. That's where the noSQL DB comes into play; adding a column (that isn't a foreign key) is just a matter of writing it to the document. Now the relational DB only has to be altered when foreign-keys/relations are added to the model. This will drastically reduce the number of table alterations.