I think the key is to see your data with through two different lenses: differentiating operational data, which is read and written by applications, from analytical data, which is used to provide business intelligence (BI).
The relational model is a beautiful thing. Schemas help avoid errors. Transactions free developers from worrying about inconsistent data. Secondary indexes let applications access data efficiently using different keys, giving developers more flexibility. All of these are good things.
But these benefits come at a cost. For example, it’s hard to spread data across many servers—something that’s required at large scale—and still provide all of these features. It can also sometimes be challenging for an application developer to map the objects in her application to relational tables. And schemas can make it difficult to deal with changing data. In situations like these, the people creating an application might instead choose to use a NoSQL solution.
So we find running on nosql to have a lot of benefits, but then we push data from our operational system into other structures when needed, like pushing orders, payments and refunds into our accounting system (via it’s only API). Or you might want to push data into Amazon RedShift in order to create a data warehouse which can be queried with a wide range of familiar SQL clients.
here’s a decent article which discusses the differences at a high-level