couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Zolton <>
Subject Re: Design considerations
Date Tue, 09 Nov 2010 13:59:13 GMT

CouchDB is known to handle many thousand databases, so I'd say that
having a database per user is a valid approach. CouchDB does however
have a configurable limit to the number of databases that can be open
at once, which you may want to read about here:

The COPY verb cannot copy a document between databases, however you'll
likely want to use CouchDB's replication to move documents between
databases. Obviously, the CouchDB guide provides a good background:

Moreover, replication filters might be a convenient way to determine
who get which documents, although I'd really have to hear more about
your scenario to give more explicit advice. Read about replication
filters here:

Finally, you'll really need to consider if/how/when folks will update
this data. If two users both want to update the same document on their
slices, and replicate their modifications back to the central
database, you're going to have to build conflict resolution into your



On Tue, Nov 9, 2010 at 3:17 AM,  <> wrote:
> I've been following recent threads with interest as I'm pretty new to couch
> but loving it's simplicity and power right now. One project I'm considering
> it for would use couch as a central document store for circa 10,000 users
> but each user may see a different "slice" of the full dataset (lets assume
> the total number of documents is ~ 10m). These slices would overlap - user 1
> might have anything from 0% to 99% of the documents in common with user 2.
> I'm assuming from the couch security model that my approach should be to
> have a different database for each user? But I have a couple of queries;
> 1) Is this approach valid?
> 2) Are there any downsides to the database per user approach (apart from the
> obvious [and potentially vast] disk space duplication)?
> 3) Does the COPY command work across databases - ie can I use it to give a
> user access to material from a central repository
> 4) Is there a better way?
> FYI It's a system I've previously built with SQL and the permissions side of
> things (who has access to what) was always a right pain in the neck - so
> much so that we were considering a database per user even then.
> Thanks in advance
> Roger

View raw message