couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <>
Subject Re: BigCouch vs. CouchDB Lounge vs. Cassandra
Date Mon, 06 Sep 2010 04:48:17 GMT

On Sep 5, 2010, at 8:49 PM, ithkuil wrote:

> What advantages does BigCouch have over Lounge?  Lounge seems fairly simple
> which is a big plus, but since Cloudant is using BigCouch in their
> commercial product that looks like a bigger plus.
> Do either of these solutions take advantage of new features like replication
> filters?
> What is the direction of internal CouchDB development in regards to
> "complete" partitioning functionality?  Is the need for Lounge or BigCouch
> (for many use cases) really a clue that if I need a completely partitioned
> distributed database I should look at something like Cassandra (do not
> like)?
> I'm sorry if you are tired of answering this question.  Please consider just
> ignoring it until you are in a really good mood.  That could be two weeks
> down the line if you like, or never.  Also, I know this could be on the user
> list, but I am asking here because I want to know what CouchDB internal
> developers think of the options and the direction for the future.

Your question is a good one.

Just my quick opinion:

It is obvious that there is a lot of demand for sharding-like features. The interwebs have
been ablaze with the news of BigCouch.

I haven't had a chance to play with it or take more than a cursory glance at the code, but
let's assume for the sake of argument that it is a top notch implementation of horizontal
scaling for CouchDB.

CouchDB wants to fit a wide array of deployment scenarios, from BigCouch to TinyCouch.

If including the sharding functionality does not have a negative effect on the ability to
run Couch simply on desktops, mobile phones, and the like, then there'd be no reason (other
than the coding effort) not to merge it to trunk.

However, one must assume that with features comes complexity. For people who don't need BigCouch
scale (I assume 90% of users) the additional complexity is only a cost, not a benefit.

For me, the question (assuming top-notch code quality) comes down to: how simple would it
be to make BigCouch a build or run-time configuration option? Does adding BigCouch to CouchDB
increase the install size and memory usage on mobile phones? Can it be added in a way that
does not present an increase in install size and administrative complexity for most users?

On the question of code quality - I can'y say much without reviewing it, but I'll say that
complexity always has a cost. In the case of BigCouch, it will take time and  work to know
exactly how it's behavior compares to regular Couch. It could be that it is 100% as reliable,
and introduces no surprises for users. Or it could be that there are subtle issues that won't
be found without wider use.

My guess is that CouchDB will ship with something like BigCouch in a future release. I think
it is healthier for the project if there is 1 code line, not a separate fork for large scale
deployments. However, I'm not sure how much work will need to be done to ensure that merging
BigCouch won't add complexity for the majority of users who aren't storing multiple TBs of


> Also, here is a tiny virtual representation of me which you can imagine
> stabbing in the eye with a tiny pencil, if that helps:
> O
> \|/
> |
> / \
> -- 
> View this message in context:
> Sent from the CouchDB Development mailing list archive at

View raw message