Multi-Tenant SaaS Architecture Explained for Founders

Sooner or later a developer or an investor will ask whether your product is multi-tenant. A large customer may ask the same thing in different words: where is our data kept, and who else can see it? Multi-tenant SaaS architecture sounds like a technical subject, but the choices inside it are business choices. They affect what the product costs to run, which customers you can sell to, and how hard it is to change course later.

We are a product engineering team at Infopark in Kochi, and we build SaaS platforms for businesses in India, the UAE and Australia. This guide explains tenancy without the jargon, so a founder can take part in the decision instead of leaving it entirely to the developers.

The short answer

A multi-tenant product is one system that many customer companies share, with each company's data kept apart from the others. There are three common ways to keep it apart: one shared database with every record labelled by customer, a separate section of the database for each customer, or a separate database for each customer. Most new products should start with the shared model and enforce the separation in the database itself. Move to a stronger model only when a customer's compliance requirements call for it.

What a tenant is

A tenant is one customer account, usually a company. It has its own users, its own data and its own settings. A user belongs to a tenant, and what that user can see is limited to that tenant's records.

An apartment building is a fair comparison. Every flat shares the same structure, lifts and water supply, which is why a flat costs less than a house. Each flat also has its own door and its own key. Multi-tenancy is the shared building. Tenant isolation is the doors and the keys.

Single-tenant and multi-tenant

In a single-tenant arrangement, each customer gets a separate copy of the software, running on its own. In a multi-tenant arrangement, all customers use one running copy.

Single-tenant is simple to reason about. One customer's data is physically apart from another's, and one customer can be given a special version. The cost shows up as you grow. Every new customer is a new installation to set up, monitor, back up and update. A fix has to be rolled out once for every customer. With five customers this is manageable. With a few hundred it becomes most of what the team does.

Multi-tenant reverses that. A new customer is a new row in a table, not a new installation. An update reaches everyone at once. Running costs are shared. The price is that the separation between customers has to be designed and tested, because it is no longer provided by physical distance.

The three ways to separate tenant data

The three models differ in how much is shared. The more that is shared, the cheaper the product is to run and the more the separation depends on careful design.

Shared schema

Every table has a column that says which customer the row belongs to, and every query is filtered by it. This is the most common model for new SaaS products because it is the cheapest to run and the simplest to update. Its weakness is that the separation is a rule, and rules can be forgotten. The answer is to have the database enforce the rule, which we cover below.

Schema per tenant

Each customer gets a separate set of tables inside one database. The separation is easier to see and to explain to a customer's IT team, and one customer's data can be exported or restored on its own. The cost is in maintenance. Every change to the structure of the data has to be applied once per customer, and that job needs tooling as numbers grow.

Database per tenant

Each customer has a database of their own. This gives the strongest separation and makes it possible to place one customer's data in a particular country or to give a heavy user more capacity. It is also the most work to operate. It suits products with a small number of high-value customers, or a premium plan offered beside a shared one.

The models can be mixed. A product can keep most customers in the shared model and place a few large ones in their own database, provided the code was written with that in mind.

How the separation is enforced

The weakest form of isolation relies on every developer remembering to add the customer filter to every query. It works until someone forgets once.

The stronger form puts the rule in the data layer. The database is told which customer the current request belongs to, and it refuses to return any other customer's rows, whatever the application asks for. Our approach is that isolation is enforced at the data layer, not in application code, and tested. A useful test tries to read one tenant's data while signed in as another, and it should run every time the product changes.

A founder does not need to know the mechanism. Ask your team two questions. What stops a bug in a new feature from showing one customer another customer's records? How is that tested? A clear answer to both is a good sign. Our guide on how to choose a software development company lists other questions worth asking.

What else tenancy touches

Tenancy is more than where data is stored. Several parts of the product hang from the same decision.

Roles and permissions. Inside each customer company, an admin and an ordinary member see different things. The permission model sits on top of the tenant boundary.

Plans and limits. What a customer is entitled to, such as number of users or volume of records, is recorded for each tenant and checked by the product.

Fair use of shared resources. One customer running a very large import should not slow the product for everyone else. Limits and background queues handle this.

Per-customer settings. Logo, custom fields and notification rules belong to the tenant. Settings are far cheaper than a separate version of the code for one customer.

Support access. Your own team needs a way to look at a customer's account to help them, with a record of who looked and when.

Leaving. A customer who cancels will ask for their data, and may ask for it to be deleted. Both should be possible without affecting anyone else.

We write the tenancy and permissions model down before it is built: how accounts, workspaces, roles and data isolation work. A few pages agreed at the start prevent arguments later. The stack we use for this kind of product is listed on our technology page.

When you do not need multi-tenancy

Not every piece of software is a SaaS product, and multi-tenancy is extra work you should not pay for without a reason.

Software for your own company. An internal system used only by your staff has one tenant. Branches and departments are handled with roles, not tenancy. This is ordinary web application work.

A system built for one client. If one customer is paying for software that only they will use, build it for them alone.

An idea that is still unproven. If you are testing demand with a prototype or a manual service, tenancy can wait until you commit to building the product. Our guide on how to build a SaaS MVP covers that stage.

If you do plan to sell the same product to many companies, decide on tenancy before the first feature is built. You can start single-tenant and add tenancy later, but it is the most expensive change we see teams make, because nearly every table and every screen has to be revisited.

How to choose a model

Four questions settle most cases.

Who are your customers? Many small businesses point to the shared model. A few large organisations point towards stronger separation.

What will their contracts require? Some customers, often in finance, healthcare or government, ask for data kept in a particular country or kept apart from other customers. Ask early prospects before you decide.

How many customers do you expect in the first two years? Hundreds of separate databases need operations tooling that a small team may not have.

Will any customer need to be restored or exported on their own? If that is a frequent need, weigh it against the lower cost of the shared model.

If the answers are unclear, the shared model with database-enforced isolation is the usual starting point. It can be extended to give a large customer their own database later, which is a far smaller change than adding tenancy to a product that has none.

Frequently asked questions

What is multi-tenant SaaS architecture?

Multi-tenant SaaS architecture is a design in which one running copy of a software product serves many customer companies, called tenants, and keeps each tenant's data and settings separate from the others.

Is multi-tenant software secure?

It can be, when isolation is enforced by the database and tested. The risk in a multi-tenant product is a mistake in the code exposing one customer's data to another. Enforcing the boundary at the data layer and testing it on every change is how that risk is managed.

Which tenancy model is cheapest to run?

The shared schema model, because all customers share the same database and the same resources. A database for each customer is the most expensive, since cost and operations work grow with every customer added.

Can we start single-tenant and add tenancy later?

You can, but it is the most expensive change we see teams make. We usually build the tenancy boundary from the start, even when the first customers are onboarded by hand.

Can one customer have a separate database while others share?

Yes, if the product is designed for it. Many products keep most customers in a shared database and place a few large or regulated customers in their own. It adds operations work, so it is usually tied to a higher plan.

Does multi-tenancy decide where our data is hosted?

No. Tenancy is about how customers are separated inside the product. Where the data is hosted is a separate choice of cloud provider and region. The two meet when a customer requires their data to stay in a particular country, which is easier to meet with a database for each customer.

Conclusion

Multi-tenancy is what makes a SaaS product economical to run: one system, many customers, one update for all. The choice between a shared schema, a schema for each tenant and a database for each tenant is a trade between running cost and strength of separation. Decide it from who your customers are and what they will require, enforce the boundary in the database, and write the model down before building on it.

If you are planning a product and are not sure which model fits, tell us who your customers are. We will ask about their requirements and your plans, and say plainly which model we would start with and why.