incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aroj George <aro...@gmail.com>
Subject Re: Multi-tenancy in Couch
Date Sat, 16 Apr 2011 06:01:07 GMT
Thanks a lot guys for all the replies, that was great help. It's great to
see such an active forum :-)

One thing I like about the one database per tenant approach is that it can
allow me to scale by
routing some of the large clients to separate database instances itself.

So the only thing left to ask, as I am quite new to couch,
are there any caveats to watch out for when going for this approach?

Rgds,
Aroj


On Fri, Apr 15, 2011 at 11:06 PM, Marcos Oliveira <marcosvm@gmail.com>wrote:

> I agree with the each tenant a database approach.
>
> We have one system in production using this strategy and works pretty
> well. The thing we had to do was create a authorization layer on our
> app to guarantee that each tenant would make requests to the right
> database.
>
> - Marcos
>
> On Fri, Apr 15, 2011 at 9:59 AM, Zachary Zolton
> <zachary.zolton@gmail.com> wrote:
> > Giving a database to each tenant is a fine way to silo data.
> >
> > As to the number of databases, see this thread:
> > http://comments.gmane.org/gmane.comp.db.couchdb.user/12160
> >
> > –Zach
> >
> > On Fri, Apr 15, 2011 at 11:45 AM, Aroj George <arojis@gmail.com> 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
> >>
> >
>

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