Just to clear up a misconception, NoSQL and its relatives (rdb, /rdb, starbase, etc.) ARE real relational databases. That's the idea - each of their application environments provides relational operators that work out-of-the-box on the tables, which happen to be (usually) TSV text files, sometimes with header lines.
IMHO, every well-read Unix hacker should at least have read this paper to see how Unix (the toolset, more than the OS proper) can be leveraged as an app platform, not just for underlying OS support: The Unix Shell as a Fourth Generation Language.
Stream/Operator databases will never flat outperform "real database engines", but they offer very real advantages, and in today's world, where the penalty for interpreted code is trivial and huge, fast harddisks and RAMdisks are dirt-cheap, the approach makes more sense than ever.
FWIW, here's a (slightly edited) post I made to the NoSQL mailing list a while back, when one of the new guys was wondering how to present NoSQL to his LUG as an alternative to "regular" SQL databases:
Well, Evan Schaffer's paper "The Unix shell as a 4GL" is a great place to start. Mainly, the advantage is not so much the database itself (DBs are just a way to hold and find stuff, after all) - it's the "stream-operator" paradigm that a database like /rdb, Starbase, or NoSQL makes possible.
This approach gives you awesome modularity and leverage, and lets non-DB people write serious DB apps without ever having to know all the arcane crap about how SQL works.
Further, in today's world where Gigabytes of RAM and RAMdisks are everywhere, speed isn't really the concern most people think it is. 4GB is actually a really LARGE database, and I'll stack up a RAMdisk against the latest snazzy FibreChannel SAN array any day! Another nice thing about using a filesystem-based table store is that you don't even need BLOBs: BLOBs are represented as the files they started out as - just drop them into the regular disk-based filesystem! If you like to work, you can keep a pointer to the BLOB's binary file in your tables, but even that's often not necessary if the directory structure and file naming scheme has been thought about very much.
Generally, people who say they need speed in databases need it to try to make up for extremely poor platform and/or application architectures - unfortunately, many of today's web apps fall into that category. Screaming DB speed isn't usually necessary, though - *good* design won't beat on the DB that hard in the first place. (A couple of years ago, I designed a high-performance deeply embedded web application server finely tuned for real-world I/O. Even though it ran on an *8-bit* microcontroller, with only about 3 KILObytes of RAM, it easily outperforms its Pentium-based competitors. That's not BS, it's true - good architecture really does make that much difference, and most modern, popular architectures are just flat *awful* from a performance point-of-view.)
Another reason this is an interesting idea: a number of years ago (literally around the dawn of Linux), RSW (Evan Schaffer's company, which wrote the commercial /rdb database that pretty much originated this whole idea) sold a product called Xrdb - a graphical (X/OpenWindows) interface to stream/operator programming. We bought a copy along with our /rdb license, and even though they kinda ripped us off becasue they never really finished the product, it was heading in a really cool direction - think of Yahoo's new Pipes, but building unix pipelines based on rdb (and other) operators, and you've got the idea. Of course, you could have separate scripts to perform certain data transformations (stored procedures, anyone?) that you could plug into the stream wherever you needed them, for stripping out phone numbers, formatting a report, whatever. Like I said, really cool, and it's about time somebody tried to build something like that again...
Really, I see stream-operator databases like NoSQL as mostly orthogonal to SQL-based RDBMSes, as both are orthogonal to specialized hybrid transactional systems such as Intersystems' M/Cache - they have different strengths, and there are good reasons for choosing each. Sadly, despite great potential, the rdb approach is the one that's still waiting for the world to notice - so go ahead and give a presentation or three...
(BTW, Carlo Strozzi, the author of NoSQL, replyed in enthusiastic agreement. He also recommended the following link on the effectiveness over efficiency approach of using text-based data: http://aplawrence.com/Opinion/textvsbinary.html)