Orchard multi tenancy without table/database proliferation

3
votes

I'm looking at implemented a muli-tenant portal solution for my SaaS application using Orchard CMS. I'm pleased that it appears multi-tenancy is a first class feature, but it looks like in order to achieve it, I've got to either a) Create a set of tables for each tenant with a table prefix or b) Have separate databases for each tenant.

I'm trying to build a solution for 10,000+ customers, and so anything that requires me to make physical data schema changes per tenant won't scale. In our SaaS application, we use a tenantID column on all tables, plus the use of nHibernate filters and a heck of a lot of indexes to allow us to scale.

I'd like to do the same in Orchard. So instead of a table for each tenant, I'd like ONE set of tables with a tenantID, and then use filters in the data access layer (NHib) to always pull the right data.

Questions:

1) Is this possible? 2) Has anyone done this? 3) Any thoughts on the best way? I was going to modify the MultiTenancy/NHiberate module source directly.

1
content-management-systemorchardcmsmulti-tenant
I don't think this is easily doable, sorry. With 10,000 customers I'm suspecting that you'd have lots of other problems as well, such as memory usage. - Bertrand Le Roy
I am also looking for exactly same scoped based multi-tenancy implementation. IMHO, creating separate tables for each tenant is horrible approach and we already started feeling huge overheads of managing hundreds and hundreds of tables for less than 50 sub-sites. @Andrew Ryan, I love to hear from you on this implementation if you proceed with scoped based implementation or not, and your experience/advice. - Firoz Ansari

1 Answers

2
votes

It is possible, but quite hard to do.

It's also most likely not a scenario for Orchard multi-tenancy, but without any further details I cannot be sure.

This feature fits best in cases where you need to have a totally independent applications and (almost) nothing is supposed to be shared between them - like in shared hosting, for instance. The major drawback is the memory overhead, because each tenant has its own copy of the whole internal object infrastructure.

A much easier approach, instead of trying to put a square peg in a round hole tweaking multi-tenancy, would be to use single tenant and implement your desired multi-tenancy scheme in a separate module on your own, from scratch. You could eg. have a "Tenant" content type and build your module around it.