Multi-tenancy describes a software architecture where a single physical installation can provide multiple logical installations. Each logical installation serves a dedicated userbase dubbed a "tenant."
Multi-tenancy is most frequently seen in the context of cloud SaaS services. Organizations that sign-up to a service become "tenants." The tenant encapsulates organization-level configuration and usually supports multiple end-user accounts. When a user logs in, they see their organization's tailored view of the service.
Why Use Multi-Tenancy?
The primary alternative to multi-tenancy is single-tenancy. In this model, each tenant receives their own standalone installation of the system. In practice, this means dedicated server infrastructure needs to be configured for each tenant.
Multi-tenancy exists purely within your application. Each tenant shares the same server infrastructure. This simplifies the setup of new tenants as you don't need to provision any extra resources. The costs of running a multi-tenant service can therefore be lower than a comparable single-tenant implementation.
Shared infrastructure also means greater operating efficiency. You might have a tenant who uses the service infrequently. With a single-tenant platform, you'd still be provisioning a dedicated installation, even though it would sit idle most of the time.
With a multi-tenant architecture, you're maintaining one set of systems. You can anticipate overall aggregate load and don't need to keep systems parked on the off-chance a tenant logs in. Resources are distributed between the active users. The flip side is that a particularly busy tenant could negatively impact the others, causing knock-on performance issues.
Multi-tenancy can be much easier to maintain over time. You've got one installation of your service which means one set of migrations. Multi-tenancy aligns well with modern software development workflows driven by continuous integration and rapid deployments. Iterating on a single-tenant system means you need to build orchestration scripts to upgrade all your tenant environments individually.
Once again, there's two sides to this: single-tenancy has a significant advantage when you want a gradual roll-out. The per-tenant isolation simplifies incremental releases where only a minority of your userbase sees a new feature on day one.
Single-tenancy also helps you accommodate individual client requests. A tenant might wish to stay on an older platform version for a little longer, giving their users 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 organisation has the same broad requirements. In this scenario, all the tenants benefit from every change that's made. The provider benefits from reduced time-to-launch and improved operating efficiency but loses a degree of tenant isolation.
Drawbacks of Multi-Tenancy
Alongside the issues described above, multi-tenancy introduces some important considerations into every application. Top of the list is security, which could be more easily compromised in a multi-tenant service.
Single-tenancy lets you put strong safeguards around each tenant's data. In a multi-tenant environment, everyone's data will exist within the same infrastructure. That means there's one centralized location for an attacker to target.
Multi-tenancy can be more demanding on developers. Each operation within your service needs to be manually scoped to the active tenant. Database tables storing tenanted resources will need to include a
tenant_id
field or similar, allowing each record to be linked to 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'll need to adjust that:
SELECT * FROM orders WHERE tenant_id = 1;
A single faulty database query could disclose the sensitive information of your other tenants.
Backing up a multi-tenant service is usually straightforward. You've only got one application installation to take care of. Challenges arise in restoration though. It's harder to selectively restore data for one tenant as all the data exists in a single dump. Providing a tenant with their data archive raises similar concerns - you'll need a custom mechanism to extract their records out of the shared infrastructure.
Hybrid Tenancy?
Some applications are moving towards "hybrid tenancy." This concept blends the best of both models. Hybrid tenancy aligns well with systems built using microservices. Some services will be single-tenanted while others will use a form of multi-tenancy.
This can help you further improve the efficiency of your architecture. You might want a multi-tenant approach to global functions, such as authentication and third-party integrations. Data generated by your service's users could 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 accelerate the launch of new features by using the approach that works best for each one. Hybrid tenancy can offer greater overall value by providing a more optimum balance between development ease, security, cost and maintenance.
There are sticking points, particularly around complexity and distribution. Artificially separating your application into single- and multi-tenant standalone services isn't the right way to approach hybrid tenancy. It tends to work best in systems which already possess clearly distinct user-facing components.
Tenant Access
Your service will probably need to store some global data that doesn't belong to any particular tenant. The list of registered tenants is one such example.
In a single-tenant system, you might have a dedicated "superuser" installation of your service. With a multi-tenant approach, you can simply have a tenants table in your database.
When a user hits your service, you need to know which tenant they belong to. A common way to identify tenants is by subdomain detection:
tenant1.example.com
tenant2.example.com
Some sites use URL paths (example.com/tenant1) or may let tenants bring their own domain name. Others will expose a single entrypoint (example.com) but then set tenant-identifying cookies or HTTP headers after a user logs in.
You also need to handle users who belong to multiple tenants. Many services now let you login with shared credentials. User records are stored globally - outside the tenanted system - and get linked into tenants by database relations. This won't always be appropriate for your system: if you provide dedicated subdomains or support tenant-provided domains, it might be undesirable to let the user "change organisation."
Summary
"Tenancy" refers to how an application handles data from multiple distinct userbases. Each tenant gets its own operating environment; how that's provisioned depends on the tenancy model.
Single-tenant services are simple but inefficient. Multi-tenant services minimise maintenance requirements but require more thought to design. Hybrid tenancy is an emerging pattern which uses microservices to combine the two approaches.
There's no go-to rule to help you determine the approach to use. Weigh up how each model performs on the attributes that matter most to you. If you're looking for strong isolation and will significantly customise your service per-tenant, single-tenancy might be best. Conversely, if you know you'll have a large number of tenants, look to multi-tenancy but keep security at the forefront of your mind.