There is just a short distance between 'I can’t see how to do this with a relational database' and 'this shouldn't be done with a relational database'.

The great strength of relational databases is that they can be adapted for a wide range of tasks. They do some things slowly or ungracefully, but a properly-designed SQL Server database can generally get the whole job done. Without blushing, I can say that I've never faced a database problem so obscure that I couldn't do it in SQL Server. Would the application have been quicker had I grabbed one or more specialised NoSQL databases, and would the performance gain would have been worth the on-cost in training and support? There is value in having a consistent architecture

So what shouldn't be done in SQL Server? Andrew C. Oliver, ('I am a NoSQLer and a big data guy') lists ten things never to do with a Relational Database in an interesting article on InfoWorld. It is a useful list to help us understand why NoSQL is sometimes chosen:

Search ('Outside of Oracle, many other RDBMS products don't have real search extensions').

Recommendations e.g. People who bought torches often bought batteries too ('that gets ugly in the RDBMS').

High-frequency trading ('High-frequency traders were among the first people to adopt and, in some cases, create NoSQL approaches. Low latency is king for HFT').

Product cataloguing ('Had we kept the product information in a graph database, it would have been simple to map').

Users/groups and ACLs: ('To some degree, LDAP was the original NoSQL database').

Log analysis: ('they really don't need transactions, and low latency is job No. 1').

Media repository: ('You're better off using some kind of distributed storage or clustered file system for your images and other binaries').

Email: ('Email really is moderately unstructured data with metadata that is best stored another way').

Classified ads: ('There's search, there's metadata, there's short-sweet content. Eventual consistency would be good enough here').

Time-series/forecasting: ('The issues surrounding time in relational databases are the stuff of legend').

I find this list fascinating, and useful to get some clarity from a NoSQL/Big-Data fan about those commercial problems for which he considers an RDBMS unsuited. I have my own views about this list, but I'd be more interested in yours, since I suspect that those people who come up with SQL Server algorithms for these problems don't necessarily share their techniques with others unprompted. Consider yourself prompted.