Determining if you should use SQL or one of the many NoSQL solutions can be a difficult decision to make. Hopefully this guide will help you in your decision making process...
Do you need a lot of flexibility in your read queries?
YES: SQL is the best choice for query flexibility since it has a well understood language for both simple and complex queries. MongoDB is also a good choice since it has some of the features of the SQL query syntax and you can add indexes on both regular and embedded documents.
NO: base your decision on other question(s).
Is it acceptable to take your application down in order to change the schema?
YES: base your decision on other question(s). Note that if you are using MySQL and have a busy server, you will have to take your application down in order to change your schema.
NO: You really need to consider your NoSQL options or commercial SQL databases. MongoDB is great in the sense that it doesn't enforce a schema on your documents. Key/value databases also give a lot of flexibility in this area since they force the schema to be in the application and not the database. With MySQL, schema changes typically are blocking operations that will cause your application to hang. This can take from seconds to hours depending on many factors (database size, server performance, etc).
Do you need transactions?
YES: Stick with MySQL or some other SQL database. SQL is the king of transactions. Some NoSQL solutions support limited forms of them (MongoDB, Redis).
NO: base your decision on other question(s).
Do your developers have experience modeling data for different kinds of databases (SQL, document, key/value, etc)?
YES: base your decision on other question(s).
NO: Then they should start off by writing some experimental apps using different databases in order to learn their quirks. Every database has "gotchas" that you really want to learn about before you start writing your application. This is especially true of NoSQL solutions if you background is in SQL.
Is your IT staff or hosting provider willing and able to support your database?
YES: base your decision on other question(s).
NO: Development costs are only one part of the picture. Once launched, it's going to need to be supported in production and every database solution requires specific knowledge in the areas of deployment, backups, monitoring, and performance tuning. You may be able to go with a hosted solution, a contractor, or full time staff if you don't want to support it on your own.
Is your application best served by using multiple types of databases at the same time?
YES: It's becoming more common to combine different types of databases within a single application. For example, If your application does lots of increment operations (think ad server counting hits or clicks) then you could use the high performance counters in Redis or MongoDB along with using SQL to store everything else.
NO: base your decision on other question(s).
Is scalability a concern?
YES: You're going to need to determine the vertical and horizontal scalability limitations of the various databases. Some databases like MySQL will scale vertically without much effort (just get a faster server). Other solutions such as Cassandra and Riak focus on scaling horizontally (add more servers), but then limit you in other ways. Another area to think about is scaling reads vs writes. Many database products have different techniques for scaling each (for example, MySQL slaves only scale reads).
NO: base your decision on other question(s).
Are you considering NoSQL for one of your projects? If so I'd like to hear from you.