# Multi-Tenant SaaS Architecture: Tenancy Models, Billing and Isolation

URL: https://zunkireelabs.com/blog/multi-tenant-saas-architecture-tenancy-models-billing-and-isolation/
Published: 2026-11-03
Summary: How to design a multi-tenant SaaS: shared vs separate databases, tenant isolation, authentication, billing, feature gating and noisy neighbours, with a checklist.

**In short:** A multi-tenant SaaS serves many customers (tenants) from one running application while keeping each tenant's data and settings separate. The central design decision is how tenants share infrastructure: one shared database with a tenant identifier on every row, a schema per tenant, or a database per tenant. Each option trades cost and operational simplicity against isolation and flexibility. Billing, authentication, feature gating and performance isolation then follow from that choice.

## Key Takeaways

- **Choose the tenancy model early.** It is hard to change after launch.
- **Shared tables with a tenant ID** are cheapest and simplest to operate, and need strict enforcement of isolation, ideally in the database itself.
- **Schema-per-tenant and database-per-tenant** give stronger separation and easier per-tenant restores, at higher operational cost.
- **Never rely on application code alone** for isolation. Add database-level controls and tests that try to cross tenants.
- **Design for entitlements:** plans, limits and feature flags should be data, not code branches.
- **Plan for noisy neighbours** with quotas and rate limits per tenant.
- Treat **tenant-aware observability and backup** as core features, not extras.

## The Three Tenancy Models

| | Shared database, shared schema | Shared database, schema per tenant | Database per tenant |
|---|---|---|---|
| How it works | One set of tables with a tenant ID column | Each tenant gets its own schema in one database | Each tenant gets its own database |
| Cost per tenant | Lowest | Medium | Highest |
| Isolation strength | Logical, must be enforced | Stronger | Strongest |
| Migrations | One change for all | Run per schema | Run per database |
| Per-tenant restore | Hard | Easier | Easiest |
| Scale to many small tenants | Excellent | Limited by schema count | Poor |
| Custom data models per tenant | Hard | Possible | Easiest |
| Best fit | Many small to mid customers | Mid-size customers with some customisation | Few large or regulated customers |

A hybrid is common: shared infrastructure for most tenants, dedicated databases for large or regulated ones.

## Enforcing Isolation

Isolation bugs are the worst kind of SaaS bug, because they leak one customer's data to another. Layer your defences:

1. **Tenant context from authentication.** Derive the tenant from the verified identity, never from a value the client sends.
2. **Database-level enforcement.** In PostgreSQL, row-level security policies can enforce that every query sees only the current tenant's rows, even if application code forgets a filter.
3. **A single data-access layer** that always applies the tenant context.
4. **Cross-tenant tests** in CI: log in as tenant A and try to read, change and delete tenant B's records through every endpoint.
5. **Separate secrets and storage paths** per tenant for files and exports.
6. **Careful caching.** Include the tenant in cache keys, or one tenant's data can appear for another.

## Authentication and Authorization

- Support **organisations with multiple users and roles.** A user may belong to several tenants.
- Offer **single sign-on** (SAML or OpenID Connect) for larger customers, usually through an identity provider or service.
- Separate **authentication** (who you are) from **authorization** (what you may do), and model roles and permissions per tenant.
- Log administrative and sensitive actions in a per-tenant **audit trail**.

## Billing, Plans and Entitlements

- Use a payments provider for **subscriptions, invoices and tax**, and keep your own record of what each tenant is entitled to.
- Model **plans, limits and add-ons as data.** Feature access should check an entitlement, not a hard-coded plan name.
- Support **usage-based charges** with reliable metering and idempotent events, so retries do not double-bill.
- Handle **lifecycle events:** trials, upgrades, downgrades, failed payments, cancellations and data export or deletion.

## Performance and Noisy Neighbours

One heavy tenant can slow everyone. Mitigate with:

- **Per-tenant rate limits and quotas.**
- **Background job queues with fair scheduling** so one tenant's big import does not block others.
- **Query and index design** that always includes the tenant in the lead position.
- **Monitoring per tenant,** so you can see who is consuming resources.
- A route to **move a large tenant** to dedicated resources.

## Operations

- **Migrations:** automate and test them. Backward-compatible changes allow zero-downtime releases.
- **Backups and restore:** know how to restore one tenant without rolling back all. This is much harder in the shared model, so plan for it.
- **Observability:** tag logs, metrics and traces with the tenant.
- **Data residency:** some customers need data in a specific region. Decide whether your design allows regional deployments.
- **Offboarding:** be able to export and fully delete a tenant's data.

## Build Checklist

1. Choose the tenancy model and write down why.
2. Establish tenant context in authentication and one data-access layer.
3. Add database-level isolation and cross-tenant tests.
4. Model plans and entitlements as data.
5. Integrate billing with idempotent usage events.
6. Add per-tenant limits, queues and monitoring.
7. Rehearse restore, export and deletion.

## How We Approach It

For multi-tenant platforms we plan in phases: strategy, foundation, features and launch. Our stack for SaaS work includes Next.js, TypeScript, PostgreSQL, Redis, Stripe, Auth0, Vercel and AWS. The aim is a foundation that can grow from a handful of tenants to many without a rewrite. See [SaaS development](/solutions/saas-development/) and the [SaaS development lifecycle guide](/blog/understanding-the-saas-software-development-lifecycle-a-comprehensive-guide/).

## The Short Version

Pick the tenancy model that matches your customers, enforce isolation in the database as well as in code, treat plans as data, protect against noisy neighbours and rehearse restore and deletion. Getting these right early is far cheaper than retrofitting them under customer pressure.

If you are weighing whether to build or buy, read our [build vs buy whitepaper](/resources/build-vs-buy-ai-software-nepal-whitepaper/).

## FAQ

**What is multi-tenant architecture?**
Multi-tenant architecture means one application instance serves many customers (tenants) while keeping each tenant's data and configuration separate.

**What is the difference between multi-tenant and single-tenant SaaS?**
In single-tenant SaaS each customer gets a separate deployment. Multi-tenant shares the application, and often the database, across customers. Multi-tenant is cheaper to run at scale, while single-tenant offers stronger separation.

**How do you isolate tenant data in PostgreSQL?**
Use a tenant identifier on every row with row-level security policies that restrict queries to the current tenant, a single data-access layer that sets tenant context from authentication, and cross-tenant tests in CI.

**How should SaaS pricing tiers and feature gating work?**
Store plans, limits and add-ons as data and check entitlements in code, rather than branching on plan names. Combine with a payments provider for subscriptions and reliable metering for usage-based charges.

**Can enterprise customers have their own database?**
Yes. A hybrid approach keeps most tenants on shared infrastructure and gives large or regulated customers dedicated databases or regions.

**How long does it take to build a SaaS MVP?**
It depends on scope. Plan in phases of strategy, foundation, features and launch, and agree the scope and timeline after reviewing requirements rather than relying on generic figures.

## Related Insights

- [Understanding the SaaS Software Development Lifecycle](/blog/understanding-the-saas-software-development-lifecycle-a-comprehensive-guide/)
- [SaaS to GaaS: How to Move From Seat Licences to Outcome Pricing](/blog/saas-to-gaas-how-to-move-from-seat-licences-to-outcome-pricing/)
- [Software Outsourcing Models: Dedicated Team vs Fixed Price vs White Label](/blog/software-outsourcing-models-dedicated-team-vs-fixed-price-vs-white-label/)

## Sources

- Zunkiree Labs, [SaaS Development](/solutions/saas-development/)
- Zunkiree Labs, [Build vs Buy AI software whitepaper](/resources/build-vs-buy-ai-software-nepal-whitepaper/)