I can't say that I've seen numbers for data sizes this big. The biggest number you've got is the rate of turnover in the database. CouchDB has quite a few read-heavy optimization design decisions, so a data flow that is lopsided toward writes might be harder to work with.
That being said, my recommendation is to check what type of throughput you can get with compaction and replication. I haven't seen numbers on either of those things, both of which would be very necessary for this scenario I think. HTH, Paul Davis On Sun, Nov 2, 2008 at 11:53 PM, Jonathan Ginter <[EMAIL PROTECTED]> wrote: > I have a similar issue. I am interested in using CouchDB to host a 200+ GB > database that will receive well over 200 million documents per day. > Moreover, the data must roll out - i.e., constant background purging - and > also support UI queries. And this is just a starting point to match the > abilities of the relational database we are already running. I will want the > DB to scale up from there. > > If there is no hope of the CouchDB being able to handle all of that - > regardless of how many machines we deploy - I would like to know that now > before I look any further into this project. > > Does anyone have a reasonable idea about whether CouchDB will be capable of > such massive scalability or how many machines it would take to scale that > large? > > I would appreciate any feedback that anyone might have on this. > > Jonathan > > -----Original Message----- > From: Paul Davis [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 02, 2008 5:30 PM > To: couchdb-user@incubator.apache.org > Subject: Re: Largest CouchDB dbs? > > Largets one I know of: > > http://www.lixo.org/archives/2008/11/02/announcing-lotsofwordscom/ > > On Sun, Nov 2, 2008 at 5:23 PM, Ask Bjørn Hansen <[EMAIL PROTECTED]> wrote: >> What are the largest known production DBs in CouchDB? >> >> I'm loading ~3M documents into a database that'll be probably around 10GB >> and then grow from there. So not very much data, but inserting and updating >> views is much slower than I expected (or thought they were in tests on >> earlier versions, is that possible?) >> >> >> >> - ask >> >
