Database Architectural Patterns For Multi-Tenant SaaS Applications
Pushpal Mazumder
CTO
19th June, 2019
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:
| Factors | Separate Database, Separate Schema | Shared Database, Separate Schema | Shared Database, Shared Schema |
| Security | High | Medium | Low |
| Flexibility | High | Medium | Low |
| Cost | High | Medium | Low |
| Maintenance | High | Medium | Low |
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.
