While I am at it, It might be worthwhile to also add the following: API - By far, one of the most appealing things about CouchDB is the RESTful API. Not only can you access CouchDB from any server and/or client environment that supports HTTP but so can the outside world. So, one's application ends up with a nice API that is already baked-in, without having to do any extra coding in order to provide it. What I am personally struggling with is how to turn it off and how to hide a few crucial cases.
Storage - CouchDB takes a couple of somewhat unique approaches to records (docs) creation and updating. It seems that for speed of execution reasons it never rewrites what is there and instead it just keeps on appending creations and updates, to the end of the file - requiring database compactions. In addition, it does not wrestle with traditional record locking by using optimistic locking and then using "_rev" to let us know when in rare cases somebody else ends up snatching a doc from underneath us and updating ahead of us. No doubt, the less work that it has to do while creating or updating documents, the more efficient and more scalable it can be or at least appear to be at that point in time, while ensuring full record durability. Incremental - In any RDBMS, one needs to both create new indices as well as have them physically built on all of the existing records, before one can use those indices. With CouchDB, all you have to do is to create your view within a design document and it will on its own build the actual "indices" (the views) the very first time that those views are actually being used. The next time that those views are used, then only newly created and/or updated docs need to be indexed. However, there seems to be mechanism in place for triggering views building before the views are used. Focus - It seems that CouchDB
