There are some companies which seem to use couchdb for large usage, for example bbc (http://enda.squarespace.com/tech/2010/3/4/couchdb-at-scale-4...). I don't know their infrastructure, but they claim to server 4 billions requests as of 4th march 2010 since summer 2009 on a 32 nodes (16 master, 16 backups). Assuming that summer starts in september to get an upper bound of the traffic, this means 250 rq/sec on average, which is nothing impressive for an infrastructure with 32 machines without more information about what they do. Generally, I would not say much about this kind of usecases, but since it is often advertised by couchdb proponents, the burden of the proof is theirs.
I agree we need to improve the interactive query capability of CouchDB.
As far as performance, the key with Couch is to keep the view generation speed faster than the insert rate. So if your users are generating less than about 1000 changes a second, you should be fine on a single server.
More than that and you may need to shard / partition, which can be done in a few different way. The leading option is BigCouch: https://github.com/cloudant/bigcouch
Actually, the numbers I get are much lower than that (almost two orders of magnitude), but I suspect it is at least partly due to bad usage of couchdb.
I am actually working on simple benchmarks representative of what we do to see if there is something worth submitting as bug issues.
here is the interview of Damian Katz concerning couchdb: http://howsoftwareisbuilt.com/2010/06/18/interview-with-dami..., which mentions that large data is not a focus.
There are some companies which seem to use couchdb for large usage, for example bbc (http://enda.squarespace.com/tech/2010/3/4/couchdb-at-scale-4...). I don't know their infrastructure, but they claim to server 4 billions requests as of 4th march 2010 since summer 2009 on a 32 nodes (16 master, 16 backups). Assuming that summer starts in september to get an upper bound of the traffic, this means 250 rq/sec on average, which is nothing impressive for an infrastructure with 32 machines without more information about what they do. Generally, I would not say much about this kind of usecases, but since it is often advertised by couchdb proponents, the burden of the proof is theirs.