Insights · 9 min read
Multi-tenancy is the decision that sets your SaaS running costs and your data-isolation risk. Here is what each isolation model costs, and how to pick without overbuilding.
By GGP Editorial
Most founders do not think about multi-tenancy until it costs them. The word sounds like infrastructure trivia, the kind of thing an architect argues about in a meeting you were not invited to. Then you sign your first paying customers and it becomes your problem: they all share the same servers, the same database, and the same monthly bill. How you split them apart decides how much the product costs to run and how painful it is to grow.
I have built SaaS products and inherited a few, and the pattern is the same every time. The multi-tenant model gets chosen in the first month and lived with for years. Pick the wrong one and you pay for it twice, once in the compute bill and once in the rework. This is the practical view, written for someone who has to make the call, not for an architect who wants a diagram.
A single-tenant product gives each customer their own copy of the software, usually their own server or their own database. A multi-tenant product runs one copy of the software that serves every customer at once, with each customer's data kept separate inside it.
Almost every SaaS ends up multi-tenant because of cost. One database, one set of application servers, one bill spread across the whole customer base. Single tenancy does not scale that way, which is why it survives mostly in enterprise deals where a large customer demands their own instance and is willing to pay for it.
The trade-off is isolation. In a multi-tenant system customers share machines, so you have to make sure one customer can never see another customer's data, and that one heavy user cannot slow everyone else down. That is the whole problem in one sentence.
There are three standard ways to separate tenants, sitting on a spectrum from cheap to expensive.
| Model | How it works | Running cost | Isolation |
|---|---|---|---|
| Shared database, shared schema | All tenants in the same tables, split by a tenant_id column | Lowest | Lowest |
| Shared database, separate schema | Each tenant gets its own schema inside one database | Middle | Middle |
| Separate database per tenant | Each tenant gets a full database of its own | Highest | Highest |
The shared schema model is where most SaaS products start. You add a tenant_id column to every table and every query filters by it. It is the cheapest to run and the easiest to build on day one. The risk is that it is also the easiest place to leak data, because the only thing keeping tenant A away from tenant B's rows is a WHERE clause someone has to remember to write on every single query.
The separate database model is the other end. Each customer gets their own database, so a leak needs a much bigger mistake, and you can restore one customer without touching anyone else. It also costs the most. Every database carries overhead, and running thousands of customers that way means a lot of operational machinery to keep track of which tenant lives where.
Founders overthink the diagram and underthink three things that matter more.
Data isolation requirements. If you sell into regulated industries, healthcare, finance, or any contract that says one customer's data must never sit next to another's, the choice is made for you. Separate databases or separate schemas become the floor, not a preference.
Per-tenant scale. Some customers are ten times bigger than others. In a shared database, one large customer's heavy queries slow everyone down. If your product has a small number of large accounts, that pushes you toward more separation. If you have thousands of small accounts, shared schema is fine.
Operational cost. Every level of separation adds something to run, monitor, back up, and migrate. The cheapest model to build is the one where a mistake hurts the most. The real question is not which model is best in the abstract, but which one your budget and your customers can live with.
The most common one I see is starting with separate databases because it feels safer, then discovering you have to build all the tooling a shared model would have given you: migrations that run across every database, a lookup that says which tenant lives on which database, and a backup and restore process that does not miss anyone.
The second mistake is the opposite. Ignore tenancy for the first six months and bolt it on later. Retro-fitting a tenant_id into a database that was not designed for it is slow and error-prone. Every table, every query, every index has to be revisited, and the bugs that hide in that process are the ones that leak data.
What I recommend is to make the decision explicitly in the first sprint instead of letting it emerge. Pick the simplest model your isolation requirements allow, build the tenant scoping in from day one, and design the data model so you can move a customer to a more isolated setup later if you need to.
Multi-tenancy is not just a database decision. It leaks into almost every part of the product.
Billing and usage. If all customers share one bill, you have to measure who used what. That means metering per tenant from the start, or you will be guessing when the invoice is due.
Onboarding and provisioning. A new tenant has to get its own rows, settings, and defaults automatically. If creating a customer involves a manual step, you have a single-tenant process wearing a multi-tenant costume.
Backups and restores. The moment you need to restore one customer's data, you learn whether your backups are per-tenant or per-database. Restoring the whole database because one customer deleted something is not a feature.
Search and reporting. Every query, every dashboard, every export has to carry the tenant filter. A reporting bug that forgets it is how a customer ends up seeing another customer's numbers.
A shared-schema product does not stay shared forever. Three signals tell you it is time to move a customer to its own schema or database.
A customer whose contract demands it. A large deal will sometimes require dedicated infrastructure, and you want the ability to grant that without a rewrite.
A customer large enough to move the needle on performance. When one tenant's traffic is a meaningful share of the whole, isolation stops being a nicety and becomes the thing keeping the product responsive.
A customer in a region with data residency rules. If a market says customer data must stay in that country, a separate database in that region is the practical answer.
The point of choosing a model is not to lock yourself in. It is to start with the cheapest thing that meets today's requirements and keep a path to more isolation for the tenants that need it.
GlobeSoft builds SaaS products on Java, Spring Boot, and Spring Cloud on the backend, with MySQL and Redis underneath and Vue or React on the front. The multi-tenant layer is one of the first things we design, because it is far cheaper to get right in week one than to retrofit in month twelve.
We have shipped subscription and platform products for clients in Brazil, South Africa, Singapore, and the US, and the tenancy question comes up in every one of them. If you want the wider picture of what a SaaS build costs and where projects fail, our SaaS development guide is the place to start, and the MVP development article covers how much to build before you have customers to isolate.
What is the difference between single-tenant and multi-tenant SaaS?
Single-tenant gives each customer their own copy of the software, usually their own server or database. Multi-tenant runs one copy that serves everyone, with each customer's data kept separate. Multi-tenant is cheaper to run and the default for most SaaS.
Which isolation model should I start with?
Start with the simplest model your isolation requirements allow, which is usually a shared database with a tenant_id column. Move to separate schemas or databases only when a customer's contract, scale, or data residency rules demand it.
Is a shared database safe enough for my customers?
For most products, yes, as long as the tenant filter is applied consistently in every query and you test it. The risk is a forgotten filter, not the model itself. If you sell into regulated industries, check whether your contracts require physical or logical separation.
Can I move a customer to their own database later?
Yes, if you design for it. Keep the data model clean and the tenant boundary explicit from day one, and a later migration to a more isolated setup is work, not a rewrite.
Does multi-tenancy affect my pricing?
It affects your margin, not your prices directly. A shared model spreads cost across many customers, so each one is cheap to serve. More isolation means more cost per customer, which is why enterprise deals with dedicated infrastructure carry a higher price.
Multi-tenancy is one of those decisions that feels small on day one and large by year two. Choose the cheapest model your customers' isolation needs allow, build the tenant boundary in from the first sprint, and keep a path to more separation open. If you are planning a SaaS and want a second opinion on the architecture, send us the outline and we will tell you which model fits and what it will cost to run.
Tell us what you are building and where you are today. We typically reply within 24 hours.
