If you are building software that many businesses will pay to use, a developer will soon ask whether it should be multi-tenant SaaS. The question sounds like an engineering detail. It is a business decision, because the answer shapes your hosting bill, how quickly you can sign up a new customer, what you can promise in a contract and how painful it is to change direction later. This guide explains the idea in plain terms, shows the main ways to build it and gives you the questions to ask before anyone writes code.
What multi-tenant SaaS means
A tenant is one customer account. Usually that is a company, with its own users, data and settings. In a multi-tenant SaaS product, every customer uses the same running application. They share the servers, the code and often the database, while the software keeps each customer’s data walled off from everyone else’s.
An apartment block is a fair comparison. One building, one lift, one water supply, and a locked door on every flat. Single-tenant software is the opposite: each customer gets a separate house, with its own plumbing to maintain.
Say a Bengaluru startup sells appointment software to clinics. In a multi-tenant design, Clinic A and Clinic B log in to the same app, perhaps on their own subdomains, and the system makes sure Clinic A can never see a single patient record belonging to Clinic B. When the startup ships a new feature, both clinics get it the same day.
Three common ways to separate tenants
Amazon Web Services describes three broad models in its whitepaper on SaaS tenant isolation strategies. The names are useful even if you never host on AWS.
Pool: everyone shares
All customers share one database. Every row of data carries a tenant ID, and every query filters on it. This is the cheapest model to run and the fastest for onboarding, because a new customer is just a new row in a table. The risk is that isolation depends on the code getting the filter right every time. Databases such as PostgreSQL offer row-level security, which lets the database itself refuse to return another tenant’s rows, so a forgotten filter in one screen does not become a data leak.
Silo: everyone gets their own
Each customer gets a separate database, and sometimes a separate copy of the whole application. Isolation is strong and easy to explain to a cautious buyer. Costs rise with every customer, and upgrades have to be rolled out to each silo, which gets slow once you have dozens.
Bridge: a mix
Most products end up somewhere in between. The application is shared, but data sits in separate schemas, or most customers share a pool while a few large ones get a dedicated database. This lets you price a premium tier around isolation without running two products.
Why the multi-tenant SaaS model you pick affects the business
- Cost per customer. Pooled designs keep the marginal cost of a small customer close to zero. Siloed designs make small customers expensive to serve.
- Onboarding. If a new customer needs an engineer to create a database, you cannot offer a self-serve free trial.
- Large buyers. Hospitals, banks and some government buyers may ask for dedicated infrastructure or data stored in a specific country. Know in advance whether your design can say yes.
- Noisy neighbours. In a shared system, one customer running a huge report can slow everyone down. Pooled products need limits and monitoring per tenant.
- Restores and deletions. If one customer deletes a month of data by mistake, can you restore only their data without rolling back everyone else? If a customer leaves and asks you to erase their records, can you do it cleanly?
Questions to ask your developers
You do not need to read the code to hold a useful conversation. Ask these and listen for specific answers:
- Which model are we using: pool, silo or a mix? Why that one for our first customers?
- Where is tenant isolation enforced? In each query, in a shared layer of code, or in the database itself?
- What test proves that one tenant cannot read another tenant’s data? Does it run on every release?
- How do we restore one customer’s data without affecting the others?
- How would we move one large customer onto dedicated infrastructure if a contract required it?
- Can we see usage and cost per tenant?
- How do customer-specific settings work? Are they configuration, or separate code?
Vague answers to the second and third questions are the ones to worry about. Those are where data leaks come from.
Mistakes to avoid
A copy of the code for each client
Agencies and early startups often start by cloning the app for each new client and tweaking it. It feels fast. By the fifth client you have five products, five sets of bugs and no way to ship one fix to everyone. If clients need different behaviour, build it as settings and feature flags in one codebase.
Relying on memory
If isolation depends on every developer remembering to add a tenant filter, someone will eventually forget. Put the check in one place that every request passes through, and back it up at the database level where you can.
No per-tenant view
Without metrics per customer, you cannot tell which accounts are profitable, who is close to a usage limit or who caused last night’s slowdown.
A simple decision rule
For most B2B products selling to small and mid-sized businesses, start with a pooled design, enforce isolation in the database as well as the code, and keep a documented path to move a single large customer into its own database. Start siloed only when your first customers are regulated buyers who will put dedicated infrastructure in the contract, or when each customer’s data is so large that sharing makes no sense.
If you are planning a first version, our SaaS development work starts with this decision in the written scope, and our technology advice service can review an existing design. A free 30-minute call is usually enough to tell which model fits your product.
Frequently asked questions
Is multi-tenant SaaS less secure than single-tenant software?
Not by default. A well-built pooled system with isolation enforced in the database and tested on every release can be very safe. The risk is concentrated in one place: if isolation fails, more customers are exposed at once. Single-tenant setups limit that blast radius but bring their own risks, such as unpatched copies that fall behind on security updates.
Can I move from single-tenant to multi-tenant later?
Yes, but it is usually a significant rebuild. You have to merge separate databases, add tenant IDs to every table, rewrite queries and migrate customers one at a time without downtime. It is far cheaper to design for multiple tenants from the start, even if your first version has only one customer.
How do customers get their own subdomain or branding in a shared app?
The app reads the subdomain or a custom domain on each request, looks up which tenant it belongs to and loads that tenant’s logo, colours and settings. Everything runs on the same code. Custom domains need SSL certificates issued per domain, which most modern hosting platforms can automate.