Single vs Multi-Tenant Apps: Which Architecture to Choose?

What are the main differences and which system would suit your project better?

One of the first decisions for a new cloud application is whether it will be single-tenant or multi-tenant. The tenancy model affects your hosting bill, how well each customer's data is isolated, and how much work it takes to onboard a new customer.

Single-tenant and multi-tenant are the two ends of a range of tenancy models. Between them sit hybrid options, such as a shared application with a separate database for each customer. Below we explain both models, compare their pros and cons, show when each one fits, and give examples of projects Go Wombat built.

What Is Single-Tenant Architecture?

In a single-tenant architecture, each customer (tenant) gets its own instance of the application and its own infrastructure. The customer's data is stored separately and is independent of any other customer.

Think of a street where every house has its own heating system: if the system in one house breaks, the neighbours are not affected.

The downside is the same as with heating: a separate system for every house costs more than a shared one. That is why SaaS products that serve many customers are usually built on shared, multi-tenant infrastructure.

What Is Multi-Tenant Architecture?

In a multi-tenant architecture, one application instance and its infrastructure serve many customers. Each customer's data is kept apart logically, for example by a tenant ID or by separate schemas or databases.

This uses resources more efficiently and costs less. The trade-off is weaker isolation: tenants are separated by application code and configuration rather than by separate infrastructure, so a mistake there can expose one tenant's data to another.

Each tenant, whether a company or an individual user, has a unique identifier that the application uses to keep its data and processes apart from other tenants. In a microservice architecture, resources can also be allocated separately to each service.

Multi-tenant applications usually let you control features at the user level: you can enable/disable features for each user or group.

To build software on the right architecture, contact Go Wombat.

Pros And Cons Of Single-Tenant Apps

Customisation

Because each customer has dedicated infrastructure, single-tenant applications allow more customisation than multi-tenant ones.

Customer Data Security

Each customer's data is isolated, so a breach in one customer's environment does not directly expose the others. This makes strict security requirements easier to meet.

Portability

Migrating one customer's data is simpler when it sits in its own database: there is less data to move, and developers need fewer migration scripts because nothing has to be separated from other tenants' data.

Single tenancy also has drawbacks:

High Cost

Separate servers and databases for every customer cost more to run, and managing them takes more of your team's time.

Complex Configuration

Every new customer needs its own deployment and database setup. As the customer base grows, keeping all these instances configured and up to date gets harder.

Low Level Of Resource Usage

Each customer's resources are reserved for that customer alone. Most customers do not use their full capacity all the time, so part of what you pay for sits idle and cannot be shared with customers who need more.

Pros And Cons Of Multi-Tenant Apps

Efficient Resource Allocation

Customers share the same resources, so capacity one tenant is not using is available to others, and less of what you pay for sits idle.

Faster Deployment

A new customer does not need a new deployment: you add a tenant to the running system. Developers can also build multi-tenant applications faster with AWS tools or those of other cloud providers.

Cost-Effectiveness

Customers share the costs of one environment, so development and maintenance cost less per customer.

Multi-tenancy has drawbacks too:

Security Concerns

Shared resources raise the stakes of a security flaw. Tenants are isolated logically, by tenant IDs, separate schemas or separate databases, so a bug in that isolation or a breach of the shared system can affect several customers at once.

Cost Separation Issues

In a single-tenant setup, each customer's infrastructure costs are easy to see. In a multi-tenant environment, working out what each customer costs you is harder, because they all use the same resources.

If you are unsure which architecture fits your app, get in touch with us.

When To Use Multi-Tenancy And Single-Tenancy

Single tenancy is the right option for industries where strong privacy is required, such as finance and healthcare.

If you create a healthcare application for the US region, it must comply with HIPAA requirements. Also, the app that stores or processes any personal data in the EU must comply with the GDPR. We have a relevant article about GDPR and HIPAA certification, and we recommend you read it.

Consumer-facing applications with many users are usually a better fit for multi-tenancy, because they serve many customers on shared cloud infrastructure such as AWS.

Single-Tenancy Use Cases

If you are building an app, single tenancy is the right option if:

Your staff is big enough to deploy, maintain, and support everything;

You don’t have many customers;

Your budget is not limited;

You need predictable high performance for each customer;

If you buy an off-the-shelf application, then the single-tenant model will be appropriate when:

Your company’s policy doesn’t provide for resource or data sharing;

You want to customise your product according to your business needs;

You can afford to pay more for higher performance.

Multi-Tenancy Use Cases

If you are building an app from scratch, choose multi-tenancy if:

You want to serve many customers in a relatively cheap cloud environment;

You don’t have a large team to deploy and maintain the product;

You need to have an easily scalable product;

If you buy software, you need multi-tenancy if:

Your company needs data and resource sharing;

You don’t need to customise software and change its configuration substantially;

You want a balance between performance and cost.

How Go Wombat Works With Multi- and Single-Tenancy

Most projects we build at Go Wombat are single-tenant, because they need full isolation. We also build multi-tenant apps.

Multi-tenant Project

Multi-tenancy works well for B2B services. One example is a travel service Go Wombat worked on: travellers book a city trip together with accommodation, local transport and activities, and travel websites use the service to combine offers from different suppliers into complete package holidays.

Here, the travel agencies are the tenants. They share common databases of trips and packages, while payments and personal details are kept separate for each tenant.

Single-tenant Project

One example is a web-based survey service for the HR department. Users create surveys for employees, choose the recipients and see the results as charts and diagrams that show what employees like, what they are unhappy with and other feedback. The product is built for one company and has an isolated, single-tenant structure.

Another is a rental management system. Guests book and pay online, and the company uses a web service to manage bookings, upcoming orders and equipment availability and to create reports. It is also used by only one customer.