
What happened to CouchDB's popularity? - firefoxman1
http://www.google.com/trends?q=MongoDB%2C+couchDB
======
rkalla
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.)

~~~
mark242
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.

~~~
jethroalias97
Also, CouchDB is all REST, so many people just write their own drivers.

~~~
mark242
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".

~~~
seanmcq
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.

------
timanglade
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.)

------
michaelbuckbee
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.

~~~
parshap
> 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.

~~~
damncabbage
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)?

~~~
jchrisa
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.

------
robterrell
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.

------
epistasis
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.

~~~
dhimes
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).

The mailing list seems excellent, FWIW.

------
mumrah
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.

~~~
rdtsc
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.

~~~
latch

      caught acknowledging
    

instant classic.

~~~
rdtsc
> caught acknowledging instant classic.

Those that can, comment, those that have nothing to say, make fun of those who
speak English as a third language.

<http://blog.mongodb.org/post/381927266/what-about-durability>

Feb, 2010

"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"

[http://www.mongodb.org/pages/viewpage.action?pageId=2752708&...](http://www.mongodb.org/pages/viewpage.action?pageId=2752708&navigatingVersions=true)

May, 2010

"MongoDB does not publish any official benchmarks...."

EDIT: Added link to blogs, quoted parent, in case gets removed

~~~
pork
A moot point since single server durability is enabled by default in Mongo
now, actually from the 1.8 stable (currently at 2.0 stable)

~~~
rdtsc
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.

~~~
pork
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.

------
latch
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 :)

~~~
illumen
Nice work :)

------
mark242
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?

~~~
rdtsc
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.

------
rch
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.

~~~
querulous
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.

------
mehwoot
Google trends is not the sole decided of popularity.

[http://www.google.com/trends?q=ruby+on+rails%2C+django&c...](http://www.google.com/trends?q=ruby+on+rails%2C+django&ctab=0&geo=all&date=all&sort=0)

Do you really think that ruby on rails has been declining in popularity since
2006?

~~~
foxylad
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.

~~~
mehwoot
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).

------
adaml_623
Wait what are the Y-axes on that graph!

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
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.

~~~
rdtsc
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.

[http://nosql.mypopescu.com/post/392868405/mongodb-
durability...](http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-
tradeoff-to-be-aware-of)

[http://blog.boxedice.com/2010/02/28/notes-from-a-
production-...](http://blog.boxedice.com/2010/02/28/notes-from-a-production-
mongodb-deployment/)

~~~
latch
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.

~~~
rdtsc
> 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:

<http://guide.couchdb.org/draft/btree.html>

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.

------
dasil003
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.

------
sologoub
The regional visualization is a bit weird. It shows Korea and Russia as the
top regions searching for Mongo and CouchDB. US is not even on the list.

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...](http://www.google.com/trends?q=MongoDB%2C+couchDB&ctab=0&geo=us&date=all&sort=0)

Seems like it's looking for the greatest difference between the two terms, as
opposed to general popularity.

------
athst
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.

------
stoph
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.

------
jtmille3
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.

------
mark_l_watson
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.

------
james33
I think you answered your own question.

------
wavephorm
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.

~~~
bauchidgw
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.

~~~
colin_jack
Couldn't agree more, I was amazed that they were prepared to sell a book as
bad as that.

------
CPlatypus
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.

------
maxogden
one of couch's strong points is that it is great at giving away your data.
most startup bros find that antithetical to their business model

~~~
InclinedPlane
Why the unnecessary use of "startup bros"?

------
electic
Why is this post dumb?

[http://www.google.com/trends?q=MongoDB%2C+sqlite&ctab=0&...](http://www.google.com/trends?q=MongoDB%2C+sqlite&ctab=0&geo=all&date=all&sort=0)

Nuff' said.

~~~
sirn
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)?

