SaaS Architecture 3 : Multi-tenancy Data Architecture

Multi-tenancy is core aspect of any SaaS architecture. All SaaS based solutions should ultimately move to multi-tenancy architecture for the business model to work. It is necessary for any SaaS offering to keep their operations overhead to minimum to actually make this financially successful business model.

Multi-tenancy is the ability to host multiple customers data on a single instance while protecting everyone's privacy. Designing Multi-tenancy application is different than designing an application for a single customer. The complexity of the design increases if applications are made highly configurable. Configurability is introduced to make applications customizable for customers to a certain extent.

In this blog, of course we will look into data architecture of a multi-tenant application.

There are three models that can be adopted.

1. Separate Database

2. Shared Database, Separate Schema

3. Shared Schema

Separate Database

Features:

1. Each tenant has it's own database
2. Data of each tenant is isolated from each other
3. Datamodel can be extended
4. Data restoration per tenant is easier is case of failure
5. Maintenance cost is higher
6. May be useful for applications that need to comply with strict data isolation requirements ( Financial or Healthcare )

Shared Database, Separate Schema

Features:

1. Each tenant has it's own schema under same database
2. Different set of tables for each tenant
3. When tenant subscribes to service, the provisioining service can create schema for the tenant
4. Data model can be extended as per tenant requirement
5. There is some degree of isolation
6. Data restoration per tenant is complex in case of failure
7. Is feasible for application with less number of tables. As no of tables increases, this approach becomes very complex

Separate Schema

Features:

1. All tenants share the same database and same schema
2. Each record is associated by a tenant ID
3. Cost of maintenance is low
4. Code need to be more robust for security so that records are accessed by corresponding tenant
5. Data model can be extended as per tenant requirement
6. There is no isolation
7. Data restoration per tenant is complex in case of failure