CAP Theorem should be the basis on which you start to make this decision: robertgreiner.com/2014/08/cap-theorem-revisited

• how is the data represented
• is consitency important
• how many writes are happening
• what roles do exist and do i want them in the datawarehouse or the application
• what replications do i need
• can i split the reads from the writes
• what does the least transformations needed to store and load the data

just the from the top of my head. usually i tend to put user as well as financial transaction data in an SQL because consistency is important.

but it's taste :)

@chilimatic has given an appreciable abstract viewpoint. One important point I think when you are on the verge of selecting NoSQL vs SQL is to ask the question, if you have to do a lot of "transactions".

I don't know about other NoSQL databases, but from what I have come to know; the NoSQL solutions' support for transactions is squeamy at best. That is why I never feel at home when I have to deal with NoSQL thingies, they propose "entities-isolated" way of thinking.

Being an old guy, you can feel right at home with SQL, if you have to deal with a lot of transactions.

I might not have the whole picture here, so please feel free to elucidate the old guy. :)

1. Do I have clear, pre-defined data structure? (If yes, then MySQL suits)
2. Do I need a reliable store? (If yes, then PostgreSQL)
3. What performance do I need? (If high, then no MySQL)

Honestly, I think that 3 questions are not enough to choose a correct database :) This guide contains a lot of useful tips on choosing a DB.