SaaS development · Multi-tenancy
Multi-tenant SaaS development with tenant isolation you can prove
We design and build SaaS products where many customers share one codebase and no customer can ever see another's data. Tenancy model, row level security, roles, billing per account and the admin tools to run it, from a team that has shipped both shared-database and database-per-tenant platforms.
Short answer
Multi-tenant SaaS development means building one application that serves many customer accounts while keeping each account's data, users and billing separate. Innovation Insight has shipped four multi-tenant platforms, two on shared databases with organisation-scoped rows and two with a database per tenant. A multi-tenant MVP costs $15k to $45k over 8 to 14 weeks and a full platform $50k to $150k+, starting with a $3k to $8k discovery sprint that fixes the tenancy model.
Reviewed by Zain Khalid Malik, CTO & Co-founder · Updated
What multi-tenancy is, and why it is hard to add later
In a multi-tenant product every customer account (a tenant) runs on the same application and usually the same infrastructure. That is what makes SaaS economical: one deployment, one version, one team. The cost is that every query, file, background job, cache key and log line now has to know which tenant it belongs to. A single missing filter shows one customer another customer's records, and that is the kind of bug that ends enterprise deals. Tenancy is cheap to design in at the start and expensive to retrofit, because it touches the data model, authentication, billing and every endpoint at once.
Choosing a tenancy model
| Model | How data is separated | Good fit | Watch for |
|---|---|---|---|
| Shared database, shared tables | A tenant ID on every row, enforced by row level security or a mandatory query filter | Most B2B SaaS: many small and mid-size accounts, fast onboarding, lowest running cost | One slow tenant can affect others; isolation depends on every policy being right |
| Schema per tenant | One database, one schema for each account | Tens to low hundreds of tenants that need custom fields or separate backups | Migrations run once per schema and slow down as tenants grow |
| Database per tenant | A dedicated database, and often a dedicated storage bucket, for each account | Regulated or enterprise customers, data residency, per-customer restore | Connection management, provisioning and migrations need automation from day one |
| Hybrid | Shared tables by default, a dedicated database for the accounts that pay for it | Products selling to both small teams and enterprises | Two code paths to test on every release |
We pick the model in discovery from four questions: who your largest customer will be, what your contracts promise about isolation and residency, how many tenants you expect in two years, and how much per-tenant customisation the product needs. The answer goes into an architecture decision record so the reasoning survives the people who made it.
What we build
| Layer | What it covers | Our usual approach |
|---|---|---|
| Tenant resolution | Working out which account a request belongs to | Subdomain, custom domain or organisation claim in the session token, resolved once in middleware |
| Data isolation | Keeping rows, files and search results inside the tenant | PostgreSQL row level security or ORM-level scoping, per-tenant storage prefixes or buckets, tenant-filtered search indexes |
| Roles and permissions | Who can do what inside an account | Role-based access control checked on the server at resolver or route level, never only in the UI |
| Organisations and invites | Teams, invitations, users who belong to several accounts | Membership table between users and organisations, account switcher, SSO for enterprise plans |
| Billing per tenant | Plans, seats, usage limits and overages | Stripe Billing with webhooks reconciled to your database; Stripe Connect when tenants bill their own customers |
| Admin console | Your support team's view across tenants | Impersonation with an audit trail, plan overrides, usage and health per account |
| Background work | Jobs, queues and scheduled tasks | Tenant ID carried in every job payload, per-tenant concurrency limits so one account cannot starve the rest |
| Tests for isolation | Proof that tenant A cannot read tenant B | Automated cross-tenant tests on every endpoint, run in CI on every change |
Multi-tenant platforms we have shipped
- Edge OCR: an AI document processing SaaS with a dedicated MongoDB database for each organisation, per-tenant connection pooling with a circuit breaker, role-based access enforced with resolver-level permission decorators, and four Stripe plans with scan limits and overages.
- GovDoc AI: a contract analysis SaaS where every account gets its own MongoDB database and S3 bucket, provisioned automatically.
- TamTracker: a B2B intelligence SaaS on PostgreSQL with organisation-scoped multi-tenancy, a separate agency portal with client impersonation middleware, and Stripe Connect billing.
- Solas: a funeral management SaaS with business-scoped multi-tenancy on MongoDB, so each funeral home sees only its own records.
Two of these use shared databases and two isolate each tenant in its own database. We have run both in production, which is why we do not recommend one model for every product. The case studies describe each architecture in detail.
Where multi-tenant builds go wrong
- Isolation enforced only in application code. One endpoint written in a hurry skips the filter. We put the rule in the database or in a single data-access layer that cannot be bypassed.
- Background jobs and exports that forget the tenant. Requests are scoped but the nightly job runs as a superuser and emails the wrong report.
- Shared caches and search indexes. A cache key without a tenant ID returns another account's data faster than the database would.
- Admin impersonation with no audit trail. Support staff need to see what the customer sees; your customers need to know when that happened.
- No plan for the noisy tenant. One account imports a million rows and everyone else's dashboard slows down. Rate limits and per-tenant queues are cheaper than an incident.
Adding multi-tenancy to an existing product
Many teams arrive with a single-tenant application that worked for the first customer and now has to serve fifty. We start with an audit of the data model, authentication and every place data leaves the system, then migrate in stages: add the tenant column and backfill it, enforce scoping in one data-access layer, turn on row level security where the database supports it, and only then open self-service sign-up. Features keep shipping during the migration, and cross-tenant tests go in first so each stage is verified.
What it costs
| Stage | Scope | Range | Timeline |
|---|---|---|---|
| Discovery and architecture | Tenancy model, data model, roles, billing design, written estimate | $3k to $8k | 1 to 2 weeks |
| Multi-tenant MVP | Sign-up, organisations and invites, two or three roles, Stripe subscriptions, core workflow, isolation tests | $15k to $45k | 8 to 14 weeks |
| Full platform | SSO, usage billing, admin console with impersonation, integrations, per-tenant analytics | $50k to $150k+ | 4 to 8 months |
| Ongoing product team | Dedicated engineers on your roadmap | From $4,000 per senior engineer per month | Monthly |
Retrofitting tenancy into an existing application is estimated after the audit, because the cost depends on how consistently the current code reaches the database.
How a project runs
- Discovery (1 to 2 weeks): customers, contracts, tenancy model, roles and the billing design, recorded as decisions you can review.
- Foundations (sprints 1 and 2): tenant resolution, organisations, roles, billing and the cross-tenant test suite, before any feature work.
- Product build in two-week sprints, with a demo each sprint and a staging environment that has at least two test tenants.
- Hardening: load test with a noisy tenant, security review of every access path, backup and per-tenant restore drill.
- Launch and growth: monitoring per tenant, then a dedicated team or retainer as the roadmap grows.
Sources and further reading
Next step
Tell us what you're building and get a written estimate.
A senior engineer replies within one business day. NDA on request.
Products we've shipped, and what happened next.
Case studies written from the technical documentation of each project: the stack, the scale and the outcome.
Questions we get asked a lot.
What is multi-tenant SaaS?
It is a software product where many customer accounts share one application and infrastructure, while each account's data, users and billing stay separate. It is the standard architecture for B2B SaaS because one deployment serves every customer.
Should each customer get their own database?
Only when contracts, regulation or scale call for it. Shared tables with enforced tenant scoping suit most B2B products and cost less to run. A database per tenant makes sense for regulated or enterprise customers who need separate storage, backups or residency.
Is row level security enough to isolate tenants?
It is a strong foundation in PostgreSQL because the database enforces the rule on every query. You still need tenant-aware file storage, caches, search and background jobs, plus automated tests that try to read across tenants.
Can you convert our single-tenant app to multi-tenant?
Yes. We audit the data model and access paths first, then migrate in stages with cross-tenant tests in place, so feature work continues while tenancy is added.
How do you handle roles and permissions?
Role-based access control checked on the server for every request, scoped to the organisation. Enterprise plans usually add SSO and custom roles; we design the permission model so those can be added without a rewrite.
How long does a multi-tenant MVP take?
Typically 8 to 14 weeks after discovery, including organisations, roles, subscription billing and the isolation test suite.