Consider, try, and perhaps even use multiple databases. It's not just a "performance" issue at play here. It's really going to come down to your requirements. How much data are you talking about? what kind of data? how fast do you need it? Are you more read heavy or write heavy?
Here's one thing you can't do in a SQL database: Calculate sentiment. http://www.slideshare.net/shift8/mongodb-machine-learning
Of course the speed in that case may not be fast enough for your needs, but it is something that's possible. With some caching of specific aggregate values, it was quite acceptable even. Why would you do this? Convenience.
Convenience really is something that you're going to be persuaded by. That's exactly why (in my opinion) NoSQL databases were created. Performance too of course, but I'm trying to discount benchmarks and focus more on other concerns.
MongoDB (and some other NoSQL) databases have some very powerful features such as built-in map/reduce. This could result in a savings both in cost and time over using something like Hadoop. Or it could provide a prototype or MVP to launch a larger business.
What about graph databases? They're "NoSQL" too. Look at databases like OrientDB. If you want to argue performance ...I don't think you're gonna show me a SQL database that's faster there =) ...and graph databases have some really amazing application based on what you need to do.
Rule of technology (and the internet) don't get too comfortable with one thing. You're gonna be limited and set yourself up for failure.