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.
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.)
This was a good analysis of why the prominent CouchDB companies didn't spent time/money evangelizing the project but it didn't cover the dramatic difference w/ how 10gen handles MongoDB.
10gen spends all their time and money marketing MongoDB. They appear to spend more marketing it than on engineering it. They can afford to do this because their "product" is MongoDB and not an alternative MongoDB based product like the prominent CouchDB companies.
Very little attention is paid to the fact that MongoDB is AGPL and that they are one of the first companies to bring the extortionware business model of the GPL to software as a service via AGPL.
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.
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.
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.
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.
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.
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.
[+] [-] rkalla|14 years ago|reply
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.)
[+] [-] mark242|14 years ago|reply
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.
[+] [-] cemerick|14 years ago|reply
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.
[+] [-] pixelcort|14 years ago|reply
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.
[1]: http://www.iterativemapreduce.org/
[+] [-] kkovacs|14 years ago|reply
I truly hope they sort it out though, since CouchDB itself is great technology.
[+] [-] timanglade|14 years ago|reply
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.)
[+] [-] mikealrogers|14 years ago|reply
10gen spends all their time and money marketing MongoDB. They appear to spend more marketing it than on engineering it. They can afford to do this because their "product" is MongoDB and not an alternative MongoDB based product like the prominent CouchDB companies.
Very little attention is paid to the fact that MongoDB is AGPL and that they are one of the first companies to bring the extortionware business model of the GPL to software as a service via AGPL.
http://www.mongodb.org/display/DOCS/Licensing http://www.10gen.com/commercial-licenses
[+] [-] michaelbuckbee|14 years ago|reply
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.
[+] [-] parshap|14 years ago|reply
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.
[+] [-] robterrell|14 years ago|reply
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.
[+] [-] epistasis|14 years ago|reply
I see that it's now using SpiderMonkey. Maybe in a few more versions I'll give it a try again.
[+] [-] dhimes|14 years ago|reply
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.
[+] [-] mumrah|14 years ago|reply
[+] [-] rdtsc|14 years ago|reply
[+] [-] sqrt17|14 years ago|reply
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.
[+] [-] latch|14 years ago|reply
[+] [-] illumen|14 years ago|reply
[+] [-] mark242|14 years ago|reply
[+] [-] rdtsc|14 years ago|reply
This is a database product, I feel that features, benchmarks, documentation, support and real use example would help more than a flashy marketing website.
[+] [-] strmpnk|14 years ago|reply
[+] [-] rch|14 years ago|reply
[+] [-] querulous|14 years ago|reply
[+] [-] mehwoot|14 years ago|reply
http://www.google.com/trends?q=ruby+on+rails%2C+django&c...
Do you really think that ruby on rails has been declining in popularity since 2006?
[+] [-] foxylad|14 years ago|reply
Google's real fail is the event tags - a grand total of NONE relate to Django the web framework.
[+] [-] dasil003|14 years ago|reply
[+] [-] adaml_623|14 years ago|reply
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.
[+] [-] johnbender|14 years ago|reply
[+] [-] rdtsc|14 years ago|reply
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.
http://nosql.mypopescu.com/post/392868405/mongodb-durability...
http://blog.boxedice.com/2010/02/28/notes-from-a-production-...
[+] [-] dasil003|14 years ago|reply
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.
[+] [-] sologoub|14 years ago|reply
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.
[+] [-] athst|14 years ago|reply
[+] [-] stoph|14 years ago|reply
[+] [-] jtmille3|14 years ago|reply
Where as MongoDB has a simple search syntax that I can create on the fly if needed in my code.
[+] [-] mark_l_watson|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] james33|14 years ago|reply