Database Architectural Patterns For Multi-Tenant SaaS Applications

Architecting databases for multi-tenant SaaS (Software as a Service) applications can be challenging and there are various aspects like security, flexibility, cost, maintenance etc. which must be kept in mind while designing such a database.

In a multi-tenant architecture, a single instance of the application serves multiple customers who all share either a database or have their own databases. The three approaches that can be followed in the case of multi-tenant architecture are:

Separate Database, Separate Schema

This architecture ensures the highest level of data security where every tenant has its own database instance physically separated. One tenant cannot access other tenant’s data.

Shared Database, Separate Schema

This architecture serves multiple tenants under the same database, where each tenant has its own set of tables grouped by schema created specifically for that tenant.

Shared Database, Shared Schema

This architecture involves using the same database and the same set of tables/schema to host multiple tenant data. A Tenant ID associates each tenant with the rows that it owns.

Pros & Cons

Each of these approaches has its own pros and cons as mentioned below:

Conclusion

A multi-tenant architecture gives the power and versatility to build an application with resource sharing in mind but you should always carefully consider the correct approach mainly based on the number of tenants, amount of stored data and security requirements.

Comments

comments