Multi-tenant SaaS architecture patterns

Multi-tenancy is the decision that quietly shapes your entire SaaS backend. Get it right and you scale smoothly to thousands of accounts. Get it wrong and you're rewriting your data layer under load, mid-growth, with customers watching. The good news: for most products the right answer is simpler than the internet suggests.

The three models

There are three canonical ways to isolate tenants, and they trade isolation against operational cost:

• Row-level (shared schema). Every table has a tenant_id column, and every query filters on it. One database, one schema, all tenants together.
• Schema-per-tenant. Each tenant gets its own PostgreSQL schema inside a shared database. Stronger isolation, more objects to manage.
• Database-per-tenant. Each tenant gets a dedicated database or instance. Maximum isolation, maximum operational weight.

Why row-level wins for most SaaS

For the overwhelming majority of B2B SaaS products, row-level multi-tenancy is the right default. It's the cheapest to operate, the easiest to run migrations against, and it scales further than founders expect. The objection is always "but isolation" - and Postgres has a strong answer.

Row-Level Security (RLS) lets the database itself enforce that a query can only see its own tenant's rows. With Supabase, RLS is the native model: you set a policy once, and even a buggy query can't leak across tenants. Combined with a tenant_id on every table and an index that leads with it, this pattern comfortably serves large customer bases.

One caution from hard experience: write RLS policies so helper functions run once per query, not once per row. A policy that re-evaluates a lookup for every row will quietly turn fast endpoints slow as tables grow. Wrap the check so the planner runs it as an init-plan.

When to reach for stronger isolation

Escalate deliberately, not reflexively:

• Regulatory or contractual isolation - a customer requires their data in a physically separate database.
• Noisy-neighbor risk - one whale tenant's workload degrades everyone else.
• Per-tenant customization - schemas genuinely diverge, not just data.

Even then, a hybrid works well: keep most tenants row-level and graduate only your largest or most sensitive accounts to dedicated databases.

Design for the model from day one

Whatever you choose, bake it in early:

• Put tenant_id on every domain table and lead your composite indexes with it.
• Never trust the client for the tenant - derive it from the authenticated session.
• Enforce isolation at the database layer, not just the application layer, so a forgotten WHERE clause can't leak data.
• Make tenant provisioning a single, tested code path.

The mistake that hurts is not picking the "wrong" model - it's leaving tenancy implicit and scattering isolation logic across the codebase. Centralize it, enforce it in the database, and you keep the freedom to evolve.

If you're designing a multi-tenant backend and want a partner who has shipped RLS-backed PostgreSQL systems at scale, talk to us. Originally published on the Doktouri Agency blog. We build web, mobile, SaaS, and AI products - let's talk.