My pers. Rules of thumb based on the behavior

SQL.

• If the data has to remain consistent at all times usually it's about money and transactions.
• If the layout of the probably wont change and should be use-able in an interface as Model

noSQL:

If eventual consistency is enough, writes are more important than reads (except graph)

Document-Based

• if I want to have an invoice which can be composed of separate parts but I don't want to change it because of relation updates
• if I don't know which data should be expected from an answer like logs
• if I need high write output but don't actually care if the data is correct at the moment or maybe the next request

Graph-Base:

• If i need to find paths between nodes and want to analyse relations
• If i have an associative n:m relation in an hierarchical structure. in sql resolving multiple n:m relations from the "generic" entry like for example a timeline which can contain documents, photos, notes, likes, people and so on.

Key-Value:

• if i want a hashmap lookup ... that's basically it usually i use it as a cache

There are cases for a column based architecture as well for example a deep table structure. "likes" for example are a classic column based architecture custom email data. But I don't really have a rule of thumb for column based databases.