couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jay Zamboni <>
Subject Re: Multi-tenancy in Couch
Date Fri, 15 Apr 2011 17:18:50 GMT
I am actually looking at CouchDb for a multi-tenant product as well.  I am
still pretty new to it, but I was looking at using the directory structure
in the couchDB name to handle the multi-tenancy in an organized way.  My end
product will have many companies, and each company with multiple users.
 Each user will then have a collection of documents.  I would have a
database for each users documents that is something like this: (Note, the
database name contains the "/" character and this tells the OS to create


I hope to have a very large number of users so I wanted to use the directory
structure to not only break things apart logically, but so that I don't end
of with a directory containing a million database files.  I am expecting
that the limitation on the number of databases is very high, but I am
interested to hear if someone has run into any bottle necks when using a
large number of databases.  For our application I only expect a low
percentage of databases to be active on any given day.

Using the "/" in the database name has been a little more troublesome than I
expected.  I did get my apache setup configured to handle this, but I was
also using Divan for some of my proof of concept, and I am not sure if Divan
can handle this or not.  Divan is not a requirement for us, it was just
convenient for our POC.


On Fri, Apr 15, 2011 at 9:45 AM, Aroj George <> wrote:

> Hi,
> What's the best way to implement multi-tenancy in couch?
> In the sql world you could choose to do either a tenant id key in every
> table or separate schemas for each tenant or even separate database
> instances...
> Similarly in couch i guess you can store each tenant's document in a
> separate database. This seems a very simple option.
> But then is there a max limit on the number of databases we can create in
> couch?
> The other option, not too hard either, is to have the tenant id as the
> first
> key in all the views and use the startkey to filter out the tenants.
> Will greatly appreciate if you can share your thoughts on which approach is
> ideal and will scale better.
> Or if there are more approaches that I have not thought off.
> Rgds,
> Aroj

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message