A SaaS product serves many customers, or tenants, from one codebase and one running system. That is what makes SaaS economical, and it is also where the riskiest design decisions sit. Most of them are cheap to make well at the start and expensive to change once customers are live.
Three ways to isolate tenants
Every multi-tenant system has to keep one customer’s data away from every other customer. There are three common designs:
- Shared database, shared tables. Every row carries a tenant ID and every query filters on it. Cheapest to run and simplest to deploy, but isolation depends entirely on the code getting that filter right every time.
- Schema per tenant. One database with a separate set of tables for each tenant. Stronger separation and easier per-tenant restores, but migrations must run once per tenant.
- Database per tenant. The strongest isolation, and useful for customers with strict compliance needs, at the price of more infrastructure and slower rollouts.
For most new products we recommend starting with a shared database and strict tenant scoping, then moving large or regulated customers to a dedicated database later. Design the code so the tenant is resolved in one place, which keeps that move possible.
Make the tenant part of every request
A leak of one customer’s data to another is the most damaging bug a SaaS product can have. Guard against it in layers:
- Resolve the tenant once per request, from the subdomain, custom domain or signed-in user, and pass it through explicitly.
- Apply the tenant filter in a shared data-access layer, not in each screen’s query.
- Where the database supports it, add row-level security as a second line of defense.
- Write automated tests that sign in as one tenant and try to read, change and delete another tenant’s records. Run them on every build.
Roles and permissions
Customers will ask for different staff to see different things. Build role-based access control early, with roles defined per tenant, and record an audit trail of who changed what and when. Retrofitting permissions into a product that assumed “everyone sees everything” touches almost every screen.
Plans, billing and feature flags
Pricing changes more often than founders expect. Keep it out of the code:
- Model plans as data: each plan switches a set of features on and sets limits such as users, records or storage.
- Check features through one function, so a new plan or add-on is a configuration change rather than a release.
- Use a billing provider such as Stripe or Razorpay for subscriptions, retries and invoices, and make sure invoices meet local tax rules, such as GST in India.
The same feature flags let you roll new features out to a few tenants first.
Onboarding and data import
Many customers arrive with years of data in spreadsheets or an older system. A guided import with validation and a clear error report often decides whether a trial turns into a paying account. Budget for it as a feature, not an afterthought.
Operations at scale
- Backups and restores: test that you can restore one tenant without rolling back everyone else.
- Monitoring: tag logs and metrics with the tenant, so you can see when one customer is slow or failing.
- Noisy neighbors: rate-limit heavy operations so one large tenant cannot slow down the rest.
- Migrations: make database changes additive and backward compatible, so you can deploy without downtime.
Keep the first version small
A minimum viable product needs secure tenancy, sign-in, the one workflow customers will pay for, and billing. Reports, integrations and a mobile app can follow once you have paying users telling you what they need.
How we can help
We build and run our own multi-tenant SaaS: Smart Class Sync, a school and college ERP with plans and feature switches, multi-campus accounts, white-label branding and role-based access with an audit trail. We bring the same patterns to cloud-native SaaS development for our clients, from MVP scoping to scale.
Planning a SaaS product? Tell us about it and we will help you choose an architecture that fits your first customers and your next thousand.