The other commenter is right - When you know what data you want to store, I'm pretty sure you can work out the storage options. For example, most apps that require a typical user registration and login can be done with a basic MySQL box or a PgSQL box.

You can use (and should use) a NoSQL database when you have data that benefits from being non-relational and storing it in a relational db will actually cause you trouble.

For example, let's assume this function:

    f(x){
     return someHeavyComputationThatRequiresALotOfTime(x);
    }

Let's say your specific use case requires that for well-defined inputs of the function f(x), you want the outputs immediately and processing this function for each request will cost you a LOT of resources (think CPU, RAM, etc.). So, in such cases, if and only if it makes business sense, you can store the inputs ranging from 0 to x and corresponding computed outputs in a NoSQL database and access it when needed, instead of actually computing it everytime.

so, your data would look something like:

    {"input": 0, "output": 143532.3434}
    {"input": 1, "output": 22342424.0934}
    {"input": 2, "output": 33242423.2423}
    {"input": 3, "output": 346324634.4546}
    {"input": 4, "output": 321144563.2457}
    {"input": 5, "output": 536573462.5646}

and so on..

Actually my example is bad because you can store the same thing on SQL db's too, but unless there is a very specific advantage[1] that these NoSQL db's have (multitudes faster read speed, lower memory consumption, etc.) you want to stay away from them.

If you are evaluating a good NoSQL db for your project, then I suggest you check out Voldemort DB[2] by LinkedIn, which is actually pretty good and has some positive feedback from people running it at scale[3] without much of the marketing layer that Mongo has.

[1] http://www.slideshare.net/nurkiewicz/projekt-voldemort-when-...

[2] http://www.project-voldemort.com/voldemort/

[3] http://engineering.linkedin.com/voldemort/voldemort-collecti...