couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Davis" <>
Subject Re: Largest CouchDB dbs?
Date Mon, 03 Nov 2008 05:23:20 GMT
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.

Paul Davis

On Sun, Nov 2, 2008 at 11:53 PM, Jonathan Ginter
<> 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
> 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 []
> Sent: Sunday, November 02, 2008 5:30 PM
> To:
> Subject: Re: Largest CouchDB dbs?
> Largets one I know of:
> On Sun, Nov 2, 2008 at 5:23 PM, Ask Bjørn Hansen <> 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

View raw message