SaaS Application: Multi-tenant architecture.

Feb 15, 2015, updated Apr 27, 2018

Most of the contents in this post is taking from Multi-Tenant Data Architecture. This is just a quick reference.

Designing single-instance, multi-tenant architecture is not that easy. It required more work to do. SaaS application is distinguished by three qualities: scalability, configurability, and multi-tenant efficiency.

Multi-tenant architecture

Three approaches for multi-tenant:

Separate Databases:

Benefits:

Tradeoffs:

Suitable: For customers that are willing to pay extra for added security and customizability. For example: banking or medical records.

Shared Database, Separate Schemas:

Benefits:

Tradeoffs:

Suitable: For applications that use a relatively small number of database tables, on the order of about 100 tables per tenant or fewer.

Shared Database, Shared Schema

Benefits:

Tradeoffs:

Suitable: when it is important that the application be capable of serving a large number of tenants with a small number of servers.

For more details read this topic Choosing an Approach

Scalability of database:

Two main tools to use when scaling out a database out are replication and partitioning.

Database clustur: deplicate databases on multible servers and load balance connection to these servers.

Ref: http://msdn.microsoft.com/en-us/library/aa479086.aspx http://django-tenant-schemas.readthedocs.org/en/latest/