Some data is just relational and works better when normalized and properly stored in a rdbms. This is especially true for data which you might want to give ad hoc reporting capabilities to.

So yes, we use both relational and nosql and both have their place. My 2 cents is start with the data, figure how and who the consumers are and how to best structure data for them then pick the most appropriate database. In some cases we have data start in mongo and then it gets processed further, refined and then ultimately dumped in MySQL for reporting and ad hoc queries.

In our Clojure web app, we started out using MongoDB, and eventually we migrated to Datomic. It's a nice compromise between relational DBs like SQL, and "dynamic" DBs like NoSQL. So far it's been a huge performance win. Queries are faster here because we have relational data, and we don't do too many writes, so the trade-off worked perfectly for us. Plus, the API is way nicer to work with than SQL-based anything.

Relational DB's are very useful. So are nosql DB's, just for different tasks. We use memcached, redis and mysql and couldn't live without any of them.

Now a days with Postgres support of JSON, can't you build your NoSQL thingy around Postgres?

Do you want to store 10 PB in a Postgres cluster and do replication yourself?

You can, not always the best tool for the job...

I should point out that I recently read that the newest version of mysql is getting json support.