I'll pipe in as a relatively new CouchDB user, and someone who's spent a reasonable amount of time in both #couchdb and #couchbase over the past few weeks.
Couchbase/CouchDB is confusing for newcomers. It was (and frankly, still is) confusing for me, and I have seen more than one person in #couchdb expressing confusion and even worried about whether the CouchDB ecosystem is stable enough to consider using Couch(x) for the data layer in serious software projects. I've been aware of CouchDB for at least a year now - the brand is well-known in certain circles. I've been aware of NoSQL and MongoDB for approximately just as long, but I'd never spent the time really looking closely at NoSQL solutions until a couple of months ago. At that time, I began seriously researching various NoSQL solutions for upcoming and ongoing projects. Frankly, the CouchDB ecosystem is the most confusing of all of the various NoSQL solutions I've researched - riak, mongodb. redis, among others. The documentation is spread out, disjointed and sometimes out of date. A number of articles and blog posts link to couch.io addresses that no longer exist (note to couchbase listeners: your move from couch.io to couchbase.com was, in my opinion, handled extremely poorly, with multitudes of dead links and a seriously broken blog that was obviously not migrated to the new system/domain with much care). As I began to research NoSQL solutions more closely, I can say that CouchDB was the brand with the most recognition for me, and was therefore one of the first solutions that I researched. I was leaning toward using CouchDB for a number of reasons - brand strength and a recommendation from another developer whose opinion I respect. I can tell you that at least in my experience, the decision to go with CouchDB over one of the other solutions took much longer than it would have, if CouchBase hadn't confused the issue, and if CouchDB's documentation had been in better order. In the end, I went with CouchDB primarily for the master-master replication, the various solutions for installing CouchDB on mobile devices, and CouchApps. To be concise, CouchDB was the correct solution for the projects we're currently working on, but it took a good deal of extra research (due to the confusion caused by CouchBase and the scattered state of CouchDB docs). In case you hadn't noticed, I disagree 100% with Bob Dionne's and Jason Smith's estimation, and I'd say that my assessment of the situation, as a new convert to CouchDB, is probably much more relevant than the estimation of two Couch(x) old hands. Couchbase is confusing for those just starting to research CouchDB, full stop. Best Regards, Kurt Milam On Wed, Mar 14, 2012 at 10:49 AM, Nick North <[email protected]> wrote: > As a fairly new CouchDb user, I have been confused about the relationship > between CouchDb and Couchbase. For some while I was unsure whether the > Couchbase site might have a more recent version of CouchDb than the CouchDb > site did, especially as it talked about a forthcoming version 2, while > CouchDb talked about version 1.1, and it contains API docs that are > perfectly usable as CouchDb documentation. > > Jan Lehnardt's Looking for Apache CouchDb > <http://www.couchbase.com/couchdb>page has done a lot to dispel that > confusion though. I don't think there is > any need for anyone to change product names, but the sort of information on > that page helps a lot to make sure people go to the right place. > > Nick > > On 14 March 2012 09:35, Jason Smith <[email protected]> wrote: > > > On Wed, Mar 14, 2012 at 9:29 AM, Bob Dionne > > <[email protected]> wrote: > > > Jan, > > > > > > Here's my two cents as a couchdb committer. > > > > > > I don't think you (Couchbase) need to do anything. My observation is > > that there has been more representation about end-user confusion than > there > > has been actual end-user confusion. > > > > Completely agree. > > >
