I've found that NoSQL databases are poor for prototyping, because you have to structure your data with the knowledge of how you'll get it out. With NoSQL the schema matches the needs of your queries. But in a prototype you don't yet know how you'll get the data out, and you'll find yourself either doing way too many queries or refactoring your schema every time you want to add a new feature to your prototype.
With a relational database, you just normalize your data and you can ask any question you want. You only need to refactor the schema if your model didn't match the real-world entities properly.
I've had to refactor my MongoDB database several times, once each time I added a new way to look at the data in the web app. Not surprisingly, I'm converging on a relational schema that takes little advantage of the nested arrays and objects possible with a document database.
If you look around you'll see that the most successful uses of NoSQL are for people who developed their app with a relational database, and now that they understand their features, can switch to NoSQL knowing exactly what to put into it to satisfy their queries. If you're still exploring your app and the kinds of questions you'll want to ask of your database, I recommend sticking to relational.
