Then there is the CouchBase "Couch Server" offering which, from what little I can tell, is membase + CouchDB and their CouchDB build, according to their docs, isn't 100% 1:1 with the Apache CouchDB builds (some differences about protocol or something).
Then you have no officially maintained libraries for the different platforms which was a turn off to me the first time I cracked that egg open.
Then you have CouchBase wanting to focus Couch on the mobile-cloud story since they are the only NoSQL solution doing that , with native builds for some of the mobile platforms.
Then you have BigCouch and IrisCouch and a slew of other things I can't figure out where they fit in.
Ultimately when you enter the eco system and start digging, it is hard to figure out exactly what "CouchDB" is, where to grab binaries for your platform from and drivers for your platform.
As wavephorm pointed out, you can figure it all out with some reading and digging, but you have to persist.
It's not like Mongo, you don't just head to the official site, grab the official binary and install the official driver.
I'd also point out that CouchDB's biggest feature, the must-have feature no other NoSQL repo besides RavenDB replicates, is the master-master replication. If you don't need that, your barrier to entry with the other NoSQL solutions is much easier/straight forward.
I hope at some point the CouchDB community focuses their efforts on barriers to entries and figures out a common message for beginners they can communicate, and from there introduce the customizations for the people that need them (mobile Couch, BigCouch, etc.)
My understanding is that version 3.0 will probably merge the Membase and Couchbase products into one, so you'll have Couchbase and Couchbase mobile.
BigCouch is a separate product from the Cloudant guys, which is essentially CouchDB with an elastic sharding layer. Cloudant also sells a hosted version of BigCouch with -- I think -- a Lucene engine on top. There will likely be some overlap here between BigCouch and version 3 of Couchbase Server.
IrisCouch is a hosted version of Couchbase, with GeoCouch thrown in as well.
"Then you have no officially maintained libraries for the different platforms which was a turn off to me the first time I cracked that egg open."
I think this comes out of the initial popularity of CouchDB-- a bunch of people wrote drivers for all kinds of languages. Some of those guys work for Couchbase now. The libraries at http://www.couchbase.org/code/couchbase-single aren't comprehensive, but they do give you a good idea as to what's out there.
There was a bit of digging involved to get a lot of driver and connection information, but it seems like the Couchbase guys are doing a great job at cleaning up what was previously a scattershot list on the Apache site.
For example-- Ektorp, one of the more popular Java libraries? Wraps the Apache HttpClient, and uses the Jackson library to parse JSON. CouchDB4J does something similar, only it uses JSON-lib. A good Java coder could probably write their own fully-functional driver in a day.
jquery.couch.js is basically just a wrapper to $.ajax().
node-couchdb uses the built in client library for node. A good node coder could probably write a fully-functional driver in an hour.
So I don't think it's a matter of "download the official driver" as much as it is "download your platform's preferred JSON parser".
As you've noted, there's lots of implementations and variants, platform targets and hosted services. What ties them all together is that you can point your CouchDB client library (or curl! :-P) at any of them, and be off and running.
While having a tip of the spear with a consistent message, canonical implementation and download, etc. is one approach (and I could certainly live with better messaging from certain places!), I think people are convinced enough by the merits of the CouchDB model to effectively route around the lack of that and some have produced fantastic (compatible / interoperable) alternatives.
(FWIW, I've been using CouchDB for a long time with a lot of apps and instances, but have been able to use all of them with Cloudant instead.)
Insofar as MongoDB's fate is tied to 10gen's, the distributed nature of the CouchDB ecosystem is actually working out quite well AFAICT.
The other unique feature is incremental MapReduce. If you need to transform your mostly unchanging data in a way more complex than a mere attribute index, the ability for CouchDB to reuse parts of the last MapReduce operation is very convenient.
Of course, if you want to do any transormations beyond one set of map and reduce operations, you're on your own. I think only [Twister] does iterative MapReduce at the moment, although I'm not sure if it is incremental or not.
I truly hope they sort it out though, since CouchDB itself is great technology.
This situation did not catch us by surprise; I flagged this as a potential issue at Cloudant and had conversations about it with the CouchOne guys back in January 2011.
What you see here is just what happens to open-source technologies when nobody spends time evangelizing them — and when maybe, just maybe, they’re not hip enough to get self-sustaining traction. I love CouchDB to pieces and believe it's an immensely useful tool with great things in its future — but it has long stopped being cool, compared to the MongoDBs and Nodes of this world. (Which is not necessarily a bad thing… Strong communities are not built on shallow attraction.)
So yes, both vendors decided to focus their limited resources on advertising their own products (successfully & deservedly so, I would argue) but I think the success & money that phase brings in will undoubtedly be funneled back into even more evangelizing & involvement in Apache CouchDB. (I'm speaking for Cloudant at least, don’t know what Couchbase’s open-source plans are for Apache CouchDB.)
That's nice, but I think that synchronization in general is less of a need as we've all become more and more connected and internet access has gotten more and more ubiquitous.
The core CouchDB devs are ex Lotus Notes guys and I get the sense that with Couch they are trying to "do Lotus Notes right" not thinking that the environment has really changed and synch is not the killer feature it once was.
I disagree. Mobile connectivity is going to continue being spotty for the foreseeable future and Couch's "store locally, sync whenever" paradigm is perfect for any application that needs to remain functional when not connected.
I'm actually pretty worried about CouchDB going away. What's out there that does the equivalent (NoSQL or Relational, I don't care)?
That said, CouchBase has a huge messaging problem. It took me hours to figure out what CouchBase and all their editions were about. I'm interested in exploring their products, the write performance improvements should be huge, but their web site definitely is confusing and off-putting.
I see that it's now using SpiderMonkey. Maybe in a few more versions I'll give it a try again.
I find it's performance reliable and repeatable (with SpiderMonkey) however. I just don't fully understand its working parameters (I also wonder how much they are likely to change).
The mailing list seems excellent, FWIW.
Those that can, comment, those that have nothing to say, make fun of those who speak English as a third language.
"We get lots of questions about why MongoDB doesn’t have full single server durability, ...there are some very practical reasons why we think single server durability is overvalued"
"MongoDB does not publish any official benchmarks...."
EDIT: Added link to blogs, quoted parent, in case gets removed
10gen sure has done a lot to keep MongoDB growing despite many people having their homework (or essential customer data, or...) eaten by MongoDB; so part of it probably is attributable to better publicity.
- fire and forget
- write with integrity check (safe)
- write with journal commit
- write with data file commit
- write with replication to X nodes
And you can combine the last 4 in any way you like.
They did a pretty good job turning a downside into a significant advantage (yes, fire and forget is a significant advantage in a lot of cases).
So 20-30 days ago only?
> yes, fire and forget is a significant advantage in a lot of cases
Sorry, but not as a default option in a DATAbase product.
This is a database product, I feel that features, benchmarks, documentation, support and real use example would help more than a flashy marketing website.
Do you really think that ruby on rails has been declining in popularity since 2006?
Google's real fail is the event tags - a grand total of NONE relate to Django the web framework.
Time to switch frameworks i guess :/
Google Trends just looks at the term being mentioned or searched for?
So maybe half those search terms are 'How do I get MongoDB to do Foo' while perhaps the documentation for CouchDB is such that a google search is not the first thing to do.
Just my thoughts on that graph anyway.
Not saying it is bad thing to optimize for speed, it is just a bit dishonest to downplay the negative effects especially after calling a product a DATA-base.
With respect to the speed of writes, MongoDB has, at least, three other things going for it [that CouchdB doesn't]: 1) the journal file is append only, 2) updates can often be done in-place, 3) a binary protocol.
When did I say that? Just cut-and-paste my phrase if you are replying to it. I don't remember saying it.
> With respect to the speed of writes, MongoDB has, at least, three other things going for it [that CouchdB doesn't]: 1) the journal file is append only, 2) updates can often be done in-place, 3) a binary protocol.
I never said MongoDB wasn't faster. It is in most situations. I was criticizing their hand-wavy attitude and what I perceived was shady marketing when it came to their trade-off. That turned me off and made me look for another product.
Besides, what exactly do those implementation features mean? CouchDB has an append-only BTRee so it doesn't need journalling:
Updates-in place are great but they again are a trade-off. Now you also need a journal.
Binary protocol -- ok. That probably makes a significant difference in some case. I would actually like CouchDB to have a msgpack or protobuf driver.
Not saying MongoDB is worse or better, it just works differently.
CouchDB caused a lot of web developers to question what they really needed out of their data store, driving a lot of early popularity, but it turns out that it's not precisely what most web apps need. MongoDB seems to be designed much more to answer this question directly, rather than solving the interesting but perhaps slightly more esoteric problems that CouchDB addresses.
When you switch to look at US searches, Chinese is somehow far outpacing English... http://www.google.com/trends?q=MongoDB%2C+couchDB&ctab=0...
Seems like it's looking for the greatest difference between the two terms, as opposed to general popularity.
Where as MongoDB has a simple search syntax that I can create on the fly if needed in my code.
The wiki is much better if you just want to get stuff working. The book is more for background.
The big issue is they don't seem to treat the documentation and client libraries as a really big deal. Look at a language like Python - it's nothing special, but it's great tutorial and documentation gets it a lot of mindshare. Heck, look at Ruby - it's Python with a bit of syntactic sugar, less libraries, and a slow interpreter. But its documentation (which is great, but offbeat) wins it rabid fans like DHH, who go on to make stuff like Rails, and it's practically a household name.
There's some really neat stuff that only CoucbDB can do, but figuring out how to use it is just a pain.
Interesting I had quite the opposite experience. It found it quite a bit better than any other NoSQL database UIs. Someone even copied it for MongoDB and stuck it on top of it.
Why do you think it was pain? And what NoSQL DB UIs have you found to be better and why?
When trying to enter a view, you need to quote and escape your code and put it all on one line. It's really bad, no novice would even know how to do this properly. I had to write my own little slash/escape tool to do it right.
Maybe a plugin interface for other syntax parsers, since, for example we use a python view server instead of a JS one.
I am still wondering what NoSQL databases have a better admin UI. I feel that Futon is pretty good and was a factor in picking CouchDB over others.
Once you've clicked into a database in Futon, choose a view to inspect/edit using the dropdown in the upper-right. Couldn't be easier, really.
There are other factors as well. I've heard some people say that Couch* is a serious memory hog. Others have complained about dependencies. The REST interface appeals to some, but others would prefer a more binary-oriented protocol. The relentless positioning vs. MongoDB, and particularly some of the FUD being slung by Couch* advocates (hi rdtsc) is generating a bit of a backlash as well. For all I know some of these issues no longer exist, perhaps some never existed, but without a focused effort to deal with these impressions they remain liabilities. Couch* comes across not only as developer-oriented, but oriented toward a particular kind of developer.
Note that none of these factors relate to the technical quality of the two products. I think Couch's general distribution/replication model is fundamentally a better one than Mongo's, though I think Mongo wins by having real ad-hoc queries instead of requiring the moral equivalent of stored procedures. I thought little of Mongo's answers regarding durability and replication (and TBH still don't think they're at the level they should be) but I could see that progress was being made and I have enough of a long-term perspective not to get all perma-caremad about it. In the end, I think Couch* has been held back a bit not by its technology but by all the "other stuff" that goes into making a project or company successful.
That said, I agree with @dasil003 above that Couch played a irreplaceable role in getting people on the NoSQL track. I speak from my own experience. Compared to Mongo, Couch allowed me to wrap my head about design differences in the NoSQL world.
It's sad to see Couch fade into obscurity, but hey!, it's initial drive, it's original story (cf. the Rubyfringe video of Damien's talk), is an important part of "NoSQL archeology" for me.