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

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

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 and the SaaS development lifecycle 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.

Related Insights

• Understanding the SaaS Software Development Lifecycle
• SaaS to GaaS: How to Move From Seat Licences to Outcome Pricing
• Software Outsourcing Models: Dedicated Team vs Fixed Price vs White Label

Sources

• Zunkiree Labs, SaaS Development
• Zunkiree Labs, Build vs Buy AI software whitepaper