Multi-tenancy mistakes that cost you at scale

Multi-tenancy is one of those architectural concerns that feels theoretical until it isn't. The decisions you make about data isolation, identity, and query patterns in the first few weeks of a SaaS product define what's possible — and what's painful — for years.

We've migrated enough products from "single implicit tenant" to "proper multi-tenant" to have a strong opinion: do it before you have customers, not after.

The three multi-tenancy models

There's a spectrum, not a binary:

Siloed: each tenant gets their own database or schema. Maximum isolation, maximum operational overhead. Right for enterprise contracts with strict data sovereignty requirements, compliance mandates, or very high per-tenant data volumes.

Pooled: all tenants share tables, distinguished by a tenant_id (or org_id) column. Lower operational overhead, easier to query across tenants for analytics, more complex to audit for data leakage. Right for most SaaS products.

Schema-per-tenant (PostgreSQL): each tenant gets their own schema within a shared database instance. A middle ground — good isolation at the query level with less operational overhead than full database siloing. Useful when tenant-level migrations or customisation are needed.

For most products: start pooled. Design for schema-per-tenant if your enterprise prospects require it.

The tenant_id that wasn't there

The most expensive single mistake is building any meaningful feature before adding tenant_id to your data model. Adding it retroactively means:

• A schema migration on every affected table
• A data backfill that assigns all existing rows to a default tenant
• Auditing every query to ensure the filter is present
• Rewriting any caching layer keyed on entity IDs that are now ambiguous across tenants

-- Every entity table needs this from day one
CREATE TABLE projects (
  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id   UUID NOT NULL REFERENCES tenants(id),
  name        TEXT NOT NULL,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- And the index to make it fast
CREATE INDEX projects_tenant_id_idx ON projects(tenant_id);

A missing tenant_id index is the second-most-common mistake. Without it, every tenant-scoped query becomes a full table scan as your data grows.

Row-level security: the safety net you want

PostgreSQL's Row-Level Security (RLS) is worth understanding even if you enforce tenant isolation at the application layer. A well-implemented RLS policy means a bug in your ORM or a missing .where({ tenantId }) can't cause a data leak — the database rejects the query.

The tradeoff is performance overhead on complex queries and additional complexity in your connection/session management. For most products, RLS is worth it in production even if you don't rely on it as the primary enforcement mechanism.

Identity and the membership model

Who belongs to what tenant, and what can they do? Design this before you write auth code.

A minimal model that scales:

• users — identity, no tenant coupling
• memberships — join table: user_id, tenant_id, role
• invitations — pending memberships, with expiry

This lets a user belong to multiple tenants (common in agency/client tools), lets you add roles without changing the user model, and lets you handle invitations without creating shadow users.

Designing this properly takes a day. Retrofitting it after shipping takes a sprint — plus a migration, plus user-facing changes to auth flows.

Cross-tenant queries

Analytics, billing, and health dashboards often need to query across tenants. If your application layer enforces strict tenant isolation, these queries require a separate administrative context — a service account that bypasses tenant filtering.

Keep that boundary explicit. An analytics query that reads from the same code path as a tenant-scoped request is an accident waiting to happen. Separate the concerns from the start.

Multi-tenancy done properly isn't glamorous. But it's the kind of foundation that makes every feature you build on top of it easier — and every enterprise sales conversation shorter.