Multi-tenant architecture is the use of a single logical software application or service to serve multiple customers. In this model, each customer is referred to as a tenant. You can provide a tenant with the ability to customize certain parts of the application, like business rules, users, displays, and database schemas. However, a tenant typically cannot customize the application code.
With multi-tenant architecture, several application instances operate in a shared environment. Each instance can serve one or more tenants. This works by running tenants on the same physical infrastructure, while keeping them logically isolated. All tenants share some aspects of the application—such as the business logic and central configuration—while having their own separate data, customizations, and user management, isolated from all other tenants.
This is part of an extensive series of guides about IaaS.
In this article:
Multi-tenant architecture is a foundational technology behind cloud computing. Cloud providers use multi-tenancy to manage multiple customers on the same infrastructure, and this is the basis for the economic benefits and elasticity of the public cloud. Private clouds can also make use of multi-tenancy, to share the same resources between multiple users, projects, or organizational units.
Multi-Tenant Architecture
The cost effectiveness made possible by multi-tenancy is possibly the biggest driver encouraging enterprises to adopt multi-tenant architectures.
Another important driver is scalability. A single platform that serves multiple public cloud customers or multiple units within an organization makes it possible to operate at a very large scale. This means that cloud users have access to virtually unlimited resources at the click of a button. If multi-tenancy was inefficient or cumbersome, cloud computing would not be possible.
When designing a SaaS application, providers must choose their tenancy model: single or multi-tenant. The tenancy model has major implications for, including the resources needed to serve the application, scalability, and operational complexity.
A single-tenant architecture provides a single instance of the software or infrastructure to one customer. This instance includes all customer data and is physically isolated from other customers. Customer data and operations are never shared with other application instances.
In this model, the provider manages the software instance on dedicated infrastructure, typically with its own database, while providing the user a high level of flexibility over software and hardware customizations.
A single-tenancy model typically provides more control and improved security for the user. However, it also increases complexity for users, because they need to configure their instance and have more limited scalability options. This model is also likely to be much more expensive for the user, while software functionality remains the same.
A multi-tenant architecture uses a single instance of the software application to serve multiple customers. All tenants share common features like security, business logic, and resource management. At the same time, each tenant is isolated from the others to protect its private data and settings. Customer data is kept confidential by permissions mechanisms that ensure each customer can only see their own data.
In this model, providers save costs, and users receive important benefits such as scalability, automated setup and ease of use. At the same time, multi-tenancy naturally creates greater security risks, as well as other concerns such as performance and reliability. The client cannot always predict in advance how their tenant will perform and whether they will be impacted by resource constraints of the provider or the activities of other tenants.
The differences between the two architectures can be summarized as follows:
Learn More: Multi-tenant SaaS
In this configuration, all tenants share a single application instance along with a single database. Each tenant’s data is differentiated and isolated within the same database using schemas or tenant-specific identifiers.
This model simplifies the maintenance and deployment of the application as there is only one database to manage. However, it may lead to challenges in scaling and data security since all data coexists in the same physical database, increasing the risk of data breaches or leakage of data between tenants.
The single application, multiple database model involves one application instance connected to multiple databases. Each tenant has its own database, ensuring data isolation at the storage level.
This model enhances data security and reduces the risk of “noisy neighbor” issues, as each tenant’s data operations are confined to their own database. However, managing multiple databases can increase the complexity of the infrastructure and may require more resources for maintenance and management.
In the multiple application, multiple database model, each tenant has their own dedicated application instance as well as a separate database. This setup provides the highest level of isolation and security among the multi-tenant architectures. It allows for extensive customization and optimization of the application per tenant, but at the cost of higher resource consumption and operational complexity. This model is typically used in scenarios where tenants require high levels of control over their environment.
Here are key advantages of multi-tenant architecture for SaaS:
Here are notable drawbacks of multi-tenant architecture for SaaS:
A common use case for multi-tenancy is to deploy applications on shared infrastructure and deliver them to multiple tenants as a SaaS application. Each organization or user accesses the application over the internet, and pays a monthly subscription fee. Here are three options for delivering a multi-tenant SaaS application to its users.
URL-based SaaS models utilize distinct URLs to direct users to tenant-specific instances of an application. This approach allows for straightforward tenant identification and simplifies routing logic. It’s particularly effective in enhancing user experience by providing each tenant a unique application URL, which can be branded or customized as needed. URL-based SaaS models are common in environments where branding and direct access are important for the tenant experience.
Multi-tenant SaaS is characterized by a single application instance serving multiple tenants, where tenants share the application and infrastructure resources. In this model, tenants are logically isolated but physically integrated within the same application environment.
This setup is cost-effective and simplifies updates and maintenance as changes need to be made only once to affect all tenants. It is suitable for applications where extensive customization is not required and where operational efficiency is prioritized.
Read SaaS Multitenancy: Components, Pros and Cons and 5 Best Practices
Virtualization-based SaaS uses virtualization technology to separate tenants onto different virtual machines or containers within the same physical server. This approach allows each tenant to operate as if they have their own dedicated server, providing a high degree of isolation and security.
It also enables better resource utilization and flexibility in resource allocation. Virtualization-based SaaS is ideal for providers needing to balance isolation with cost-efficiency, especially in resource-intensive applications.
One of the main challenges when building multi-tenant applications is managing user identities. Multi-tenant applications require managing users in the context of their tenants, in such a way that each user belongs to a tenant:
The authentication process is as follows:
The authorization process is as follows:
Learn more: Multi-Tenant Authentication
Use the following best practices to ensure a multi-tenant architecture is secure:
In a nutshell, Frontegg’s PLG-centric and end-to-end user management platform is multi-tenant by design.
By developing the platform to the essential requirements of the B2B SaaS, we know that each tenant has its own configurations, user sets, and security settings. This is why Frontegg allows each environment to hold segregated sets of tenants, assign users to each one of them, and hold a separate configuration for each one of them in a way that doesn’t affect the neighboring tenants in any way or form.
In the complex B2B world, each customer requires fine grained control on each configuration. That requires professional products to keep pace with these requirements and develop a multi-tenant capable infrastructure from day one. Frontegg just makes it easier.
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of IaaS.
Authored by NetApp
Authored by Spot
