Nesting in your primary data store is an anti-pattern for information workloads where you need to ask questions against your data Consider: { "name"

Nesting in your primary data store is an anti-pattern for information workloads where you need to ask questions against your data Consider: { "name": "Sam", "age": 12, "friends" [ { "name": "Tom", "age": 15 } ] } Attributes like name and age are properties of a person entity, when placed in a JSON hierarchy something else is happening, the one dimensional relationship the things have between each other is also being saved into the structure That's dangerous because relationships should be formed on read, not on write, otherwise you concrete all future reads towards whatever it was on write, and if you're particularly sloppy the data gets duplicated which is even worse The solution is to normalise your data store and use relational algebra to reify relationships at runtime The problem with mainstream databases is they don't force normalisation, automatic indexing and pulling off attribute level normalisation is unworkable performance wise, so in most teams this doesn't work but this idea does work if you want to try this out learn Datomic