A lot of this is the result of the confusion in the community, there is the CouchDB Apache project, then the CouchBase work and their own "Single Server" releases that don't necessarily map 1:1 to the Apache versions.
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.)
Couchbase offers 3 products -- Couchbase Server (which is Membase, with an instance of CouchDB for persistant storage). Couchbase Single Server (which is CouchDB plus Geocouch plus a few other addons). Couchbase Mobile (self-explanatory).
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.
I think it's also important to add-- writing a "driver" for Couch is, basically, writing an API that essentially calls some HTTP library with some options set, and then parses the resulting JSON data.
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".
This is true until you realize you'll need to support keepalive and chunked encoding to write a reasonbly good driver. Two things that often require significant effort, if not custom coding, to make work with http libraries.
The interesting thing about CouchDB is that it's actually more like an HTTP storage and query API/protocol than a particular database implementation.
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.
> 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.
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][1] does iterative MapReduce at the moment, although I'm not sure if it is incremental or not.
I have to agree. Not long ago, the biggest advantage of CouchDB for those new to NoSQL were its simplicity and "relax". Lately it really has disappeared into IBM-esque product combination offerings.
I truly hope they sort it out though, since CouchDB itself is great technology.
CouchOne abandoned any sort of marketing effort around CouchDB long before they got acquired by Membase. Since then, they have focused their attention solely on marketing the Couchbase brand, with close to zero time spent evangelizing Apache CouchDB. The other CouchDB “vendor”, Cloudant (who I work for) never had much of a marketing budget, so we spent no time marketing CouchDB either (we focused on building and marketing our own products, open-source BigCouch and hosted Cloudant).
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.)
One of CouchDB's standout features is that it handles synchronization of data across devices (not that it doesn't potentially do other things well, but I think the conventional wisdom for a while was: "If you want to do synchronization use 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.
Agreed. I'm using CouchDB for a front-of-house ticketing system; the roving units need to sync back to main base (surviving disconnections thanks to spotty wireless). CouchDB is perfect for this.
I'm actually pretty worried about CouchDB going away. What's out there that does the equivalent (NoSQL or Relational, I don't care)?
CouchDB won't go away, at least not as long as HTTP and JSON are relevant. If you'd like to see more open source contributions, do what I did and learn the code base, contribute patches and ideas.
I'm using CouchDB every day and could not replace it with Mongo if I wanted to. So I guess I don't care how popular it is with others, since it solves my problems today (and it's at least popular enough to be maintained and improved).
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.
About a year ago I built a prototype system on top of CouchDB, and it turned out to be very flaky when I went to install it elsewhere. The javascript engine (was it Rhino?) was super hard to install from source, and the distribution packages on Ubuntu were unreliable. I really like the concepts of CouchDB, and it's really influenced how I think about designing systems for future projects, but I was going to wait for it to mature more before I pushed on it again.
I see that it's now using SpiderMonkey. Maybe in a few more versions I'll give it a try again.
I too built a prototype using couch. The thing that scares me is that the database gets really huge and has to be compacted "by hand." I'm not exactly sure when to run the compactions when lots of users are on as I understand that it can create some performance problems.
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).
If we're comparing CouchDB's popularity to that of MongoDB's, it's simple - 10gen. 10gen has done a very good job generating lots of hype around their product. I believe they have people dedicated to this task (aka, evangelists). CouchBase on the other hand, has not done so well at this.
And that hype turned me off. I have an allergic reaction to it. Especially when they were caught acknowledging they didn't have default durability for their writes. Then suddenly they removed their benchmarks from their site and made some comment about how data will be lost anyway, so it is not a big deal.
"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"
Not moot for someone who already chose a different product because of that. These decision are extrapolated and people infer the quality and seriousness of engineering from such decisions. Those, in my opinion, matter more than marketing or flashy websites.
That's a fair point, but the product as it stands is very usable for me. Even if they never updated it, I would keep this build as something that is more than adequate for what it does.
It's also that CouchDB is (or at least used to be) rather slow compared to MongoDB.
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.
There is a reason they are fast. They didn't use to have durability. Think about that -- it is a database product that until the last version didn't have durability and its writes were not acknowledged with a response. If you store you data in memory and write it to disk sometimes, you can write very fast.
a bit of self-ego inflating (feel free to bust me down a notch though), but between the C and D points in the MongoDB line, which was quite a spike, The Little MongoDB Book and the mongly.com tutorials went live :)
Go to one of the http://www.couchbase.com/couchconf-world-tour CouchConf days and ask your question again. The San Francisco edition was exciting; anyone know how New York turned out?
Why not invest that time and effort in product features and development instead of marketing, hype, cons & webinars.
This is a database product, I feel that features, benchmarks, documentation, support and real use example would help more than a flashy marketing website.
It was smaller scale but really polished. The content was more complete in NYC where SF was just making announcements of really alpha products. (I spoke at both and can say my own talk got a lot better).
I think Couch simply started moving in the wrong technical direction at some point - mostly because of an unhealthy preoccupation with running on cell phones.
The whole platform obsession is definitely hurting CouchDB. Attempt to investigate it's suitability as a data store and you're left with the impression that it's only appropriate for some vaguely defined couchapp ideal.
Quite possibly. The Twitter debacle tainted RoR's reputation (fairly or not), and there is a concern that Ruby might turn out to be a flash in the pan. Django/Python is just as effective, and enterprises feel far more comfortable with Python's depth of support across the board.
Google's real fail is the event tags - a grand total of NONE relate to Django the web framework.
I dunno, RoR is so widespread now compared to where it was in 2006. I think, because it is widespread now, people don't have to search for "ruby on rails" because they don't know what it means. You are going to be searching for something more particular now. I guess that's sort of my point of what could be happening with CouchDB (I don't use it... so I have no real idea).
As a consultant I've only seen Rails increase in popularity. Rails is definitely more popular today than 2 years ago, even though all the hype has faded. More and more large companies are using it nowadays, even for critical systems.
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.
Having worked with neither of them my perception is that MongoDB has "better performance". While I would never rely on that for making decisions about which to use, I'm sure that has some real consequences, particularly where search popularity is concerned.
You just don't know about the other side of the coin -- no durability to start with. You'll be flying fast, until one day you realize your data is corrupted.
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.
Seriously, now you are just spreading FUD. You even said a few posts up that there WAS durability.
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.
> You even said a few posts up that there WAS durability.
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:
From a rubyist's perspective, CouchDB was a major catalyst in reigniting interest in non-SQL databases—a long-standing cyclical occurrence—this time in the realm of web development.
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.
It may be superficial, but I wonder how much naming and marketing could be a factor. The name sounds a little bland if you don't know what it is. I wasn't that interested to learn more about it until I went to a meetup where a guy explained it in much clearer language and gave some examples as to where it could be useful.
My issue with CouchDB is the basic approach. Instead of maintaining indexes, the goal of CoachDB is to pre-cache all search functions with the actual result, for all records. This takes a lot of disk space for certain use-cases. This difference makes MongoDB a more attractive choice than CouchDB.
I don't know about anyone else, but using CouchDB feels like I am writing nothing but stored procedures to return the simplest of searches in CouchDB land.
Where as MongoDB has a simple search syntax that I can create on the fly if needed in my code.
I use MongoB much more often than CouchDB, but I think that Cloudant's BigCouch open source project is great: easy to set up and a lot of scaling headroom. A nice auto sharding and replication layer on top of CouchDB.
I'm not entirely surprised. CouchDB is very clunky and minimalist. And documentation is really, really horrible. The futon UI is a pain to use. I had to write my own library for nodejs because all the existing code I found was terribly written and poorly documented. It just goes on and on. And I like the technology, I persisted and eventually learned to be sort of proficient with CouchDB. But I doubt other people will go to the same lengths.
ad documentation: i bought the oreilly couchdb book to get some decent introduction, and lets just say it made me doubt the editorial standards (if there is such a thing) of oreilly - a lot.
You can get it for free. It's basically a series of blog posts (by a number of authors) which tries to explain some of the technical workings of CouchDB, and a few neat things you can do with it. It's kind of deep, but not comprehensive enough, and doesn't really cover the basic practicalities very well.
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?
Things like adding users, and restricting a database to particular users, was a nightmare to figure out.
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.
The first thing I did on that page was add "membase" to the list. If one adds the "couchdb" and "membase" lines, the result almost - no, not quite - keeps up with the MongoDB line. This is compatible with my first thought that people have had trouble keeping up with Couch's continual changes in name and direction. Relatedly, Couch* (the company) has often failed to provide a comprehensive solution, requiring users to grab other pieces from other places - e.g. BigCouch from Cloudant or Futon from the Apache project. Contrast with 10gen/MongoDB: consistent name, consistent direction, single source for the whole solution including client drivers.
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.
While I understand where you're coming from, Max, this is really dangerous delusion. Couch just lost the drive it had in the beginning, for whatever reasons, crazy focus on "data liberation" and cell phones included.
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.
I don't get it. Is there anything wrong with SQLite being more popular than MongoDB (possibly except the fact that I don't expect to see MongoDB visible in the graph)?
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.)