Because you're not limited in building your topology, it is highly applicable for clusters - as well as for offline apps: You can use an offline version of your CouchDB, and when getting online again the data will be synched with the master(s) on the net (a bit like Google Gears). This will become extremly useful especially for wikis and other collaboration tools. (Jan Lehnardt told me that a CouchDB-based wiki is in preparation; I am looking forward to see it listed on wikimatrix).

The JSON-objects are just stored in b-trees using key→value (where value is the complete document); there are no SQL-like querymethods. But there are views, which aren't evaluated on-the-fly: the view-related data is stored in the DB, too. This smells a bit like materialized views in Oracle, but CouchDB is better: the views are updated only when the affected documents are changed.

Anyway, managing data is quite different from RDBMS, and you have to develop different approaches when using CouchDB. Because JSON is a native Ajax format, web browsesr can directly connect to CouchDB. Because CouchDB can manage binary data and render html directly, its possible to write wep apps completely driven by CouchDB (a wiki for example). A propos rendering html: this is done in constant memory (besides of that CouchDB already has a very low memory footprint); in contrast: if you put a separate presentation layer on top, you usually have to buffer all the content gathered (to compose the layout). I understand that writing complete webapp apps in CouchDB is fun and a good proof of concept, but I think that won't address commercial environments, where CouchDB must find its place in the existing business environment.

CouchDB is a very interesting technology; it has the power to become a fundamental part in web architectures - as lucene did years before.