Multi-Tenant SaaS Architecture: Shared Schema, Row Level Security or a Database per Tenant?

What multi-tenant architecture means

A multi-tenant SaaS product serves many customer accounts, called tenants, from one application. The architecture question is how you keep each tenant's data separate while sharing as much infrastructure as possible. There are three standard answers, and the choice affects cost, onboarding speed, compliance and how hard the product is to operate. This guide explains each model, where it breaks, and how we chose between them on four products that are in production today.

The three tenancy models compared

Model 1: shared tables with row level security

Every table that holds customer data gets a tenant ID column. In PostgreSQL you then enable row level security on the table and write a policy that only returns rows whose tenant ID matches a value set for the current session or carried in the user's token. From that point the database itself refuses to return another tenant's rows, even if a developer forgets a WHERE clause. Supabase builds its whole authorisation model on this feature, which is one reason row level security now appears in so many job briefs.

• Strength: one schema, one migration, one connection pool. A new customer is a new row, so self-service sign-up is instant.
• Strength: reporting across all tenants for your own analytics is a single query.
• Weakness: a table without a policy, or a role that bypasses row level security, exposes everything. Table owners and superusers skip policies by default, so the application must connect as a role that does not.
• Weakness: one tenant's heavy query competes with everyone else's. You need indexes that lead with the tenant ID, query timeouts and rate limits.

If your database or ORM does not support row level security, the same model works with scoping enforced in one data-access layer. It is weaker, because the rule lives in code that can be bypassed, so back it with automated tests that try to read across tenants. We used organisation-scoped rows for TamTracker on PostgreSQL and business-scoped documents for Solas on MongoDB.

Model 2: schema per tenant

One database, with a separate schema (a namespace containing its own copy of every table) for each tenant. The application switches schema per request. Isolation is clearer than a tenant ID column, and you can back up or customise one tenant. The cost appears in operations: every migration runs once per schema, so a release that takes seconds with ten tenants takes many minutes with a thousand, and a migration that fails halfway leaves tenants on different versions. Schema per tenant suits products with a modest number of larger customers who need per-tenant customisation. It is rarely the right choice for self-service SaaS.

Model 3: database per tenant

Each tenant gets a dedicated database, and usually dedicated file storage. This is the strongest isolation short of separate deployments. A customer can be restored, exported, moved to another region or deleted without touching anyone else, and a security questionnaire that asks whether data is stored separately gets a plain yes.

The price is automation. You need a catalogue that maps tenants to connections, a provisioning job that creates and migrates a database at sign-up, a migration runner that upgrades every tenant and reports failures, and connection management that does not open thousands of idle pools. On Edge OCR we gave each organisation its own MongoDB database with dynamic model loading, per-tenant connection pooling and a circuit breaker on connections. On GovDoc AI every account gets a dedicated database and S3 bucket, provisioned automatically, because the product handles government contract documents.

How to choose

Isolation is more than the database

Teams that get the tables right still leak data through the parts around them. Whichever model you choose, check each of these.

• File storage: per-tenant prefixes or buckets, and signed URLs that expire. A guessable public URL is a data leak.
• Caches: the tenant ID belongs in every cache key.
• Search indexes and vector stores: filter by tenant on every query, or use an index per tenant. This matters for AI features, where retrieval can pull another customer's document into an answer.
• Background jobs: carry the tenant ID in the job payload and set the tenant context before any query runs.
• Logs and analytics: tag events with the tenant, and keep customer data out of shared log lines.
• Admin tools: staff impersonation needs its own permission and an audit record the customer can ask for.

Roles and permissions inside a tenant

Tenant isolation answers which account a user belongs to. Role-based access control (RBAC) answers what that user may do inside it. Keep the two separate: a membership table links users to organisations with a role, and permissions are checked on the server for every request. Users who belong to several organisations are normal in B2B products, so model membership as many-to-many from the start. On Edge OCR permissions are enforced with decorators at resolver level alongside subscription guards, so a role check and a plan check happen in the same place.

Billing follows the tenant

Subscriptions, seats and usage limits attach to the organisation, not the user. Store the plan and its limits in your own database and update them from payment-provider webhooks, so the application never has to call the provider to decide whether a feature is allowed. If your tenants bill their own customers, as agencies do on TamTracker, you need a platform model such as Stripe Connect. Our API development and integration page covers how we make those webhooks safe to retry.

Testing tenant isolation

1. Seed two tenants with similar data in every test environment.
2. For every endpoint, add a test that signs in as tenant A and requests a record that belongs to tenant B. It must fail.
3. Run the same checks against background jobs, exports and search.
4. Run the suite in CI on every pull request, and treat a failure as a release blocker.
5. Before launch, run a load test in which one tenant sends heavy traffic, and watch the other tenant's response times.

Moving between models later

Going from shared tables to a database per tenant is possible, but it is a project: export one tenant's rows, load them into a new database, switch the connection and verify nothing was missed. It is far easier if every table already has a tenant ID, no query joins across tenants and all data access goes through one layer. Going the other way, from many databases to shared tables, is rarer and harder, because primary keys collide. This asymmetry is why we advise starting with shared tables unless you already know you need physical separation.

We design the tenancy model during a $3k to $8k discovery sprint and record the decision before any feature work. See multi-tenant SaaS development for how we build these foundations, and the SaaS development cost guide for budgets.

Sources

• PostgreSQL documentation, row security policies: https://www.postgresql.org/docs/current/ddl-rowsecurity.html
• AWS Well-Architected Framework, SaaS Lens: https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-lens.html
• Microsoft Azure Architecture Center, tenancy models for a multitenant solution: https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/tenancy-models
• Supabase documentation, row level security: https://supabase.com/docs/guides/database/postgres/row-level-security
• Innovation Insight case studies: Edge OCR, GovDoc AI, TamTracker, Solas