hmmm.... interesting, but still as soon as you need something untraditional that CouchDB doesn't provide, you are out of luck. There is a good reason why app layer is used almost universally.
Another way to simplify people's life would be using something like Oracle's Berkeley DB. Small app layer, with embeded database that can be called with simple api calls, makes more sense. No SQL, no separate database to maintain, yet it is a very powerful persistence layer. It would be just as easy to distribute, plus you can do your own custom coding, and fancy stuff that CouchDB would not be able to provide.
Berkeley DB is very much the same idea as couchdb, a persistent hash. What's interesting about couchdb is the REST API that makes use of JSON and the use of Erlang/OTP. Erlang was built by and for telecom apps. It's robustness and scalability are phenomenal.
Couchdb also includes a map/reduce framework based on javascript. It's really worth a close look. The one thing I don't quite get is why they haven't used Mnesia instead of rolling their own storage model. Perhaps because it wasn't designed for very large datasets.
There was a limitation with Mnesia that each file could only be 2GB at the most. Recently, it was announced, that there was a replacement for the underlying engine for Mnesia called Tokyo Cabinet the removed the limitation.
CouchDb seems fairly fast for large datasets--the caveat being, once the index is built on first access.
Another way to simplify people's life would be using something like Oracle's Berkeley DB. Small app layer, with embeded database that can be called with simple api calls, makes more sense. No SQL, no separate database to maintain, yet it is a very powerful persistence layer. It would be just as easy to distribute, plus you can do your own custom coding, and fancy stuff that CouchDB would not be able to provide.