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.