Architecture and comparisons
Multi-tenant SaaS or separate instances: how to choose the architecture
It is the first decision behind a platform sold by subscription, and the hardest one to change later. Here we define the terms, compare the models on the criteria that really matter, and explain why two of our products went opposite ways.
Written by Maximilian Giurastante. . 10 minute read.
A multi-tenant SaaS platform is an application where several customers (the tenants) use the same installation and the same infrastructure, with their data kept apart by a tenant identifier on every row. In the separate instances model each customer gets its own copy of the application and of the database. Multi-tenant costs less per customer and is updated once for everyone; separate instances isolate more and can be customized more.
In short
- Multi-tenant means one installation for every customer and a tenant identifier on every piece of data; separate instances mean one copy of the application and of the database per customer.
- AWS calls the three models silo (everything separate), pool (everything shared) and bridge (shared application, separate data). Microsoft describes the same models for the database: one per tenant, shared, sharded, hybrid.
- The shared model pays off with many small customers and little customization; the separate model with a few large customers that ask for isolation, data residency or a version of their own.
- The technical risk of the shared model is one query without the tenant filter: you mitigate it with reviews, tests and rules inside the database, not with trust.
- LeavePilot uses the shared model because it serves many small companies with the same product; Allestio creates a database per organization because it serves companies that want their data kept apart. The difference is in the customers, not in the technology.
- An order of magnitude for a complete multi-tenant platform: from 15,000 to 40,000 euros and three to six months; a database per customer adds operations work, not development work.
The definitions, before the opinions
The tenant is the customer seen as an organization: a company with its own users, its own data and its own settings. The question "multi-tenant or not" asks where the border between one tenant and the next runs: in the code, in the database or in the infrastructure.
Names change from vendor to vendor but the models are the same. The Microsoft guide to database tenancy patterns lists: a single-tenant application with a single-tenant database, a multi-tenant application with a database per tenant, a multi-tenant application with one shared database, a shared database split across several shards, and a hybrid model. In practice it always comes down to deciding whether the border between customers sits in a column, in a database or in an installation.
Where the border between one customer and the next runs
Three columns. Separate instances: three lanes, each with an application and a database per customer. Shared multi-tenant: one application and a single database with the tenant identifier on every row. Hybrid: one shared application and a database for each customer.
- Separate instances (silo): App A, DB A, App B, DB B, App C, DB C. Maximum isolation, three installs to update
- Shared multi-tenant (pool): One application (for every customer), One database (tenant_id on every row). Lowest cost per customer, one single update
- Hybrid (bridge): One shared application (for every customer), DB A, DB B, DB C. Separate data, one codebase, migrations per database
The comparison on the criteria that really matter
No model wins on every criterion. The table is there to show which criteria your case is sensitive to: if you sell to small companies you read the first rows, if you sell to public bodies and large enterprises you read the last ones.
| Criterion | Shared multi-tenant | Separate instances | Hybrid (database per tenant) |
|---|---|---|---|
| Cost per customer | The lowest: shared resources | The highest: dedicated resources | Low for the application, medium for the databases |
| Data isolation | Logical: a column and a filter | Physical: different installations | Physical for the data, logical for the application |
| Updates | One for everyone, in one go | One per instance, even at different versions | One codebase for all, migrations for every database |
| Customization | By configuration, within the product | In the code too, per customer | By configuration, with its own data and limits |
| Effect of one customer on the others | Possible: a heavy customer slows down the rest | None | Reduced: the database is not shared |
| Data residency and deletion | Per row: deleting a tenant is a query you have to get right | Per installation: you shut it down | Per database: you drop the database |
| Risk of error | A query without the filter exposes another customer's data | Low | Low on the data, still open on the application |
| Operational complexity | Low | High: it grows with every customer | Medium: database creation has to be automated |
| Onboarding a new customer | One row in a table | A new installation | A new database, created through an API |
| When it pays off | Many small customers, the same product for all | Few large customers, contractual requirements | A mixed base, or customers who ask for separate data |
Two products, two opposite choices, for the same reason
We have built both models, and not as an experiment: the customers of the two products are different. The model follows the customers.
LeavePilot: shared, because the customers are many and small
LeavePilot handles holidays and time off for companies that often have fewer than twenty employees, with a free plan up to five. A database per company would cost more than the revenue from that company. So every company sits in the same database, every row carries the company identifier, and the filter is applied in one place in the code, so it does not depend on the memory of whoever writes the next query. An update is one update for everyone, the same evening.
Allestio: a database per organization, because the customers are event production companies
Allestio is a management system for audio-video companies and event production firms. There are fewer customers, they are larger, and their data (inventories, layouts, photos from site) is their work: they want to know it sits somewhere of their own. When an organization is created the platform provisions a dedicated database through the provider API, and a central catalog keeps the list. Inside each database, twenty-nine tables out of thirty also carry the project identifier: isolation on two levels. The price is that every schema migration has to be applied to every database, with a script that runs them one after another.
The same decision, read on the two products
| Question | LeavePilot | Allestio |
|---|---|---|
| Who the customers are | Many small companies, some of them on the free plan | Fewer companies, with data that is their work |
| What they ask about their data | That it works and costs little | That it stays separate and portable |
| Model chosen | Shared, identifier on every row | A database per organization, plus a project identifier |
| Cost of a new customer | One row | A database created through an API, a few seconds |
| Cost of an update | One migration | One migration per database, one after another |
| Where we paid the most | In the tests with several companies and in the checks on the filter | In automating provisioning and migrations |
How to choose, in four questions
The decision comes from looking at the customers, not at the technologies. These four questions are almost always enough; if the answers are mixed, the answer is the hybrid model.
- How many customers, and how much does each one pay? If revenue per customer is a few tens of euros a month, the cost of a dedicated database eats it: shared model. If it is hundreds or thousands, the dedicated database is a small line in the bill.
- What do the customer contracts ask for? Public bodies, healthcare, finance and large companies often want it in writing: where the data sits, who can read it, how it gets deleted. A database per tenant answers with a fact; the shared model answers with a procedure. Both can be fine, but the first is easier to explain.
- How different is the product from one customer to the next? If every customer wants its own rules, fields and integrations, the shared model turns into a maze of conditions. Separate instances work better, or a hybrid with configuration per tenant, and better still is to ask whether you are selling a product or a service built to order.
- Who will run the infrastructure two years from now? A hundred separate instances are a hundred installations to update, monitor and back up. If nobody is there to do it, the shared model or the hybrid with automated provisioning are the only options left standing.
The market pushes toward shared platforms: Gartner put worldwide spending on public cloud services at an estimated $723.4 billion for 2025, up from $595.7 billion in 2024, with software as a service as the largest item. Buyers now expect the SaaS model; the architectural choice is about how to give each customer the isolation its contract asks for, without everyone paying for it.
Costs and timelines
The model you pick moves the cost from building the product to running it. The orders of magnitude are the ones on our costs page; here we say what changes from one model to the next.
| Item | Shared multi-tenant | Database per tenant | Separate instances |
|---|---|---|---|
| Building the platform | from 15,000 to 40,000 euros, three to six months | The same, plus automated provisioning and migrations | The same, plus the install scripts for each customer |
| Onboarding a customer | No technical cost | A few cents or euros a month per database | Hours of work and dedicated resources |
| Updates | Included in maintenance | Included, with one extra step | Billed by time, for every instance |
| Monthly infrastructure | From a few tens to a few hundred euros in total | Similar, with one more database per customer | Per customer, from tens to hundreds of euros |
The decision has to be taken before the first table is written, because moving a product from one model to the other after launch is work comparable to rewriting it. If you are weighing up a platform, the SaaS platforms page describes how we work on isolation, subscriptions and roles, and how we work and what it costs gives the full orders of magnitude.
Frequently asked questions
What is a tenant in a SaaS platform?
The tenant is the customer seen as an organization: a company with its own users, its own data and its own settings. A multi-tenant platform serves several tenants from the same installation; every user belongs to one tenant and sees only the data of that tenant.
Is multi-tenant less secure than separate instances?
Not in itself: security depends on how it is built. In the shared model the specific risk is a query without the tenant filter, and you prevent it by applying the filter in one place, testing with more than one tenant and using row-level security in the database. With separate instances the risk moves onto the installations, which all have to be kept at the same level.
When does a database per customer pay off?
When the customers are relatively few, they pay enough to cover the cost of a dedicated database, and their contracts ask where their data sits or how it gets deleted. It is the model we chose for Allestio, which serves companies whose inventories and layouts are their work.
Can you move from one model to the other after launch?
You can, but it is work comparable to rewriting the data layer: every query, every migration and every backup script changes. That is why the choice belongs before the first table, based on the customers you intend to serve, and should not be put off.
How much does it cost to build a multi-tenant SaaS platform?
The order of magnitude is from 15,000 to 40,000 euros and three to six months for a complete platform with data isolation, subscriptions, roles and an admin panel. A database per customer adds automation work, not product development. The variables that weigh most are integrations and payments.
Sources
The figures quoted in the text, each linked to the original document. Numbers are reported as published by the source, with the year they refer to.
- AWS, SaaS Tenant Isolation Strategies (whitepaper): Definition of the silo, pool and bridge models for tenant isolation. Published on 1 August 2020 and kept today as a historical reference; the same models come back in the SaaS Lens of the Well-Architected Framework.
- AWS Well-Architected Framework, SaaS Lens: Bridge model: The hybrid model, with a shared application and dedicated resources for some tenants.
- Microsoft Learn, Multitenant SaaS database tenancy patterns: The tenancy patterns for the database: single-tenant, database per tenant, shared database, sharded shared database, hybrid, with the comparison table on scale, isolation, cost and complexity. Updated on 21 August 2025.
- Microsoft Learn, Architectural approaches for storage and data in multitenant solutions: Models for distributing data in multi-tenant solutions. Updated on 21 August 2026.
- Gartner, Gartner Forecasts Worldwide Public Cloud End-User Spending to Total $723 Billion in 2025: Press release of 19 November 2024: spending on public cloud services estimated at $723.4 billion for 2025, up from $595.7 billion in 2024.
Written by Maximilian Giurastante
Founder and software developer, MAXYMIZE. Designs and builds SaaS platforms, custom business software and automations with language models. Over twenty years as a project leader in technology, audio and video systems integration.
Are you designing a subscription platform?
Bring us your typical customers, even just three profiles. In thirty minutes we tell you which isolation model holds up in your case and what it means for the cost of running it.