Easy implementation of queries using sql like syntax along side custom built ones which has been very helpful when we have different teams building reports against same datastore without having them interfering or conflicting over their changes. As well its ability (or lack there off) to store large volumes efficiently while still being fast enough was one area. i found us missing out during initial prototyping phase but since then they reworked performance issues so should be fine going forwardFor smaller datasets. I would say noSQL fits better however if you need complex aggregate functions this can't handle everything easily. A good combination between relational db's speed & quality results + more efficient nonrelational stores.