If you deal with multi-tenant SaaS apps, the main architectural concern is the database layer, which is also called the persistence layer. The main issues that need to be addressed are the level of tenant data isolation, difficulties with restoring data and data encryption.

Separate Application and Database Instances for Each Tenant

In this model, an instance of the application is installed for each tenant. Each application instance has its own database, with the tenant’s data contained in that single database. Thus, each tenant has sole access to an installed application and its corresponding database.

This model makes it easy to extend the database and customize the application per the tenant’s requirements, if it is necessary.

Multi-Tenant App with One Database per Tenant

In this model, there is 1 multi-tenant application with many databases. Each tenant have its own separate database. And since there is 1 application instance in this case and multiple tenants have access to the application, there are two ways to scale the application in case of increased workloads:

• The first one calls for more resources per node;
• The second one adds more nodes to the application.

Scaling the databases is a separate issue. Moreover, sometimes there is no need to scale it ⁠— if the database is provisioned to handle the expected initial and future workloads, and that each database instance has been optimized from the start.

Multi-Tenant App with a Single Multi-Tenant Database

This model also presupposes that there is a single application for all tenants. But in this case all tenant data is pulled in a single database.

This model is one of the simplest because all tenant data reside in a single database. It means there is only one database to manage, which is relatively easy to do. But as more tenants are added to the database, managing that single database might become challenging.

Multi-Tenant App with Sharded Multi-Tenant Databases

Maksym Babych, a Saas product expert, notes that this model combines a single multi-tenant application with sharded databases containing multiple tenants. The data for each tenant resides in a single sharded database.

This model has the best scalability potential, since it distributes tenants across multiple databases. Since each tenant data residing in its own shard, there is no adverse effect on application performance when work is done on the tenant data.

Summary

A SaaS market has a lot of software solutions to offer. All of them employ different database architecture. It is highly important to consider the database architecture while designing an application and I hope this article will help you to choose the right one for your business needs.