You could also arge that adopters 'sql style RDBMS' end up building a NoSQL datastore.
If you find you are using a lot of EAV, polymorphic associations, multicolumn attributes, trees, graphs it might be a better option to go down one the on of the many NoSQL routes. Key/Value, Column Stores, Document and Graph databases. Sometimes you can make huge gains in design simplicity because you persistance and/or queries map far more cleanly.
An interesting example of "NoSQL" on top of an "RDBMS" is Salesforce [1].
A huge upside to RDBMS in my view is that they are 'well understood' in production, and operations know how to deal with them.
It is a big design space out there, and you can make a lot of tradeoffs :)
[1] http://www.infoq.com/presentations/SalesForce-Multi-Tenant-A...
Two things:
1. Most day-to-day problems involve relationships among entities. It's not stodgy or wrong to use a good RDBMS when that's the problem you're dealing with.
2. Many NoSQL adopters wind up building a relational database on top of something else. That's a fun job, but not everyone can afford to ditch 40 years of R&D and pretend they've invented something. I think a lot of the allure in implementing these solutions comes the hype, promise of a silver bullet-like solution, and the opportunity to dabble the intricacies of creating a database.