Multi-tenancy describes a software architecture where a single physical installation can provide multiple logical installations. Each logical installation serves a special user base called a “tenant.”
Multi-tenancy is most often seen in the context of cloud SaaS services. Organizations that sign up for a service become ‘tenants’. The tenant includes organization-level configuration and typically supports multiple end-user accounts. When a user logs in, they see the custom view of their organization’s service.
Why use multi-tenancy?
The primary alternative to multi-tenancy is single-tenancy. In this model, each tenant gets their own standalone installation of the system. In practice, this means that a dedicated server infrastructure must be configured for each tenant.
Multi-tenancy exists purely within your application. Each tenant shares the same server infrastructure. This simplifies setting up new tenants because you don’t need to provision additional resources. The cost of running a multi-tenant service can therefore be lower than a comparable single-tenant implementation.
Shared infrastructure also means greater operational efficiency. You may have a tenant that uses the service infrequently. With a single-tenant platform, you would still provision a dedicated installation, even if it would be idle most of the time.
With a multi-tenant architecture, you maintain one set of systems. You can anticipate the total total load and do not have to keep systems parked in the event that a tenant logs in. Resources are shared between the active users. The flip side is that one particularly busy tenant can negatively impact the others, leading to performance issues.
Multi-tenancy can be much easier to maintain over time. You have one installation of your service, which means one set of migrations. Multi-tenancy fits well with modern software development workflows driven by continuous integration and rapid deployments. Iterating on a single-tenant system means building orchestration scripts to upgrade each of your tenant environments individually.
There are also two sides to this: single-tenancy has a major advantage if you want to roll out gradually. The per-tenant isolation simplifies incremental releases where only a minority of your user base sees a new feature on day one.
Single-tenancy also helps you meet individual customer requests. A tenant may want to stay on an older platform version a little longer so that their users have more time to prepare for change. There’s no need for everyone to move together when tenants can be migrated individually.
Multi-tenancy works best when every organization has the same broad requirements. In this scenario, all tenants benefit from every change that is made. The provider benefits from a shorter startup time and improved operational efficiency, but loses some degree of tenant isolation.
Disadvantages of Multi-Tenancy
In addition to the issues described above, multi-tenancy introduces a number of important considerations to any application. At the top of the list is security, which can be more easily compromised in a multi-tenant service.
With single-tenancy, you can place strong safeguards around each tenant’s data. In a multi-tenant environment, all data will reside within the same infrastructure. That means an attacker can target one central location.
Multi-tenancy can be more demanding for developers. Each operation within your service must be manually mapped to the active tenant. Database tables that store leased resources must have a:
tenant_id field or something similar, allowing each record to be associated with its tenant.
In a single-tenant application, where each tenant gets its own standalone installation, the following database query might be acceptable:
SELECT * FROM orders;
In a multi-tenant environment, you need to adjust that:
SELECT * FROM orders WHERE tenant_id = 1;
A single bad database query can expose the sensitive information of your other tenants.
Backing up a multi-tenant service is usually easy. You only need to take care of one application installation. However, there are challenges in restoration. It is more difficult to selectively restore data for a single tenant because all data is in a single dump. Providing a data store to a tenant raises similar concerns: you need a custom mechanism to extract their records from the shared infrastructure.
Some applications are moving towards ‘hybrid rental’. This concept combines the best of both models. Hybrid leases are a good fit for systems built using microservices. Some services will be single-tenanted, while others will use some form of multi-tenancy.
This can help you further improve the efficiency of your architecture. You may want a multi-tenant approach to global features, such as authentication and third-party integrations. Data generated by the users of your service can then be stored separately, using multiple instances of a single-tenant service.
Using a mix of single- and multi-tenant services gives you more flexibility. You can speed up the launch of new features by using the approach that works best for each feature. Hybrid leases can provide greater overall value by providing a more optimal balance between ease of development, security, cost, and maintenance.
There are bottlenecks, especially with regard to complexity and distribution. Artificially separating your application into single and multi-tenant standalone services is not the right way to approach hybrid tenancy. It usually works best in systems that already have distinctly different user-facing components.
Your service probably needs to store some common data that doesn’t belong to a particular tenant. The list of registered tenants is an example of this.
In a single-tenant system, you may have a special “superuser” installation of your service. With a multi-tenant approach you can easily have a
tenants table in your database.
When a user reaches your service, you need to know which tenant they belong to. A common way to identify tenants is through subdomain discovery:
Some sites use URL paths (
example.com/tenant1) or let tenants bring their own domain name. Others will expose a single access point (
example.com) but then set tenant identifying cookies or HTTP headers after a user logs in.
You also need to deal with users that belong to multiple tenants. Many services now allow you to log in with shared credentials. User records are stored globally – outside the tenant’s system – and are associated with tenants through database relationships. This is not always appropriate for your system: if you specify special subdomains or support tenant-provided domains, it may be undesirable to have the user ‘change organization’.
“Tenancy” refers to how an application handles data from multiple different user bases. Each tenant gets his own operating environment; how that is set up depends on the rental model.
Single-tenant services are simple but inefficient. Multi-tenant services minimize maintenance requirements, but require more design attention. Hybrid rental is an emerging pattern that uses microservices to combine the two approaches.
There is no go-to rule to help you determine which approach to use. Weigh how each model performs on the features that matter most to you. If you’re looking for strong isolation and want to significantly customize your service per tenant, single-tenancy may be best. Conversely, if you know you will have a large number of tenants, look to multi-tenancy, but keep safety first.