posted 9/9/2013 06:20 PM
Technical programming journals, websites and blogs are littered with people's views and assertions about the decision between single tenancy or multi-tenancy. In layman's terms multi-tenancy means all customers share a single database and single "instance" of the program, with their data stored in a shared database tagged as being for one customer or another. Customizations are therefore limited to what they can do within those database tables. With single tenancy each customer has their own independent database and instance of the system, in their own folder on the server.
Each of these options comes with associated pros and cons. Within the context of enterprise-grade social collaboration and networking (and specifically the customizable Communifire) we'd highlight these virtues of single tenancy over multi-tenancy:
Against all these benefits stands only a single significant inconvenience: upgrading. But this too can be seen as a positive. In a multi-tenancy system all customers are upgraded at once, in a single push of new code. This is great for systems where everyone is doing the same thing and users accommodate and cope with change well. In a single tenancy system, in contrast, each customer has to be upgraded separately. But that also means each customer can be upgraded separately. The customers gain control over when and how an upgrade takes place. They may choose to delay or maybe even skip an upgrade cycle because it comes at a particularly busy time for the customer and they don't want to disrupt their users with change. Being in control over their community is a virtue for most of our customers.
Developers for any system have to make this decision based on their situation and needs. With Communifire, given the flexibility we offer our customers and the amount of control our customers like to have, there is a clear case for single tenancy. We don't want to impose any limitations on our customers, which is why we choose single tenancy.