Multi-Tenancy Done Right: The Architecture Decisions That Matter

Multi-tenancy is one of those architecture topics that feels handwave-able in diagrams and becomes vicious in production. Pick the wrong model early and every feature you ship will either bend around it or require a migration. Here's the decision tree we use.

Three models, briefly

• Shared everything: one database, one schema, tenants identified by a column. Cheapest to run, hardest to isolate.
• Shared database, separate schemas: one DB, schema-per-tenant. Decent isolation, noisy neighbors still possible.
• Database-per-tenant (or cluster-per-tenant): full isolation, real cost, real operational weight.

What actually drives the decision

It isn't technology — it's customer profile.

• SMB customers, many of them, low ACV: shared everything. You can't afford per-tenant infrastructure at $50/month seats.
• Mid-market, some compliance asks: shared DB with strong row-level security and audit logs. Schema-per-tenant if customers ask for data isolation specifically.
• Enterprise, VPC/compliance hard requirements: database-per-tenant or even dedicated deployment. The price tag reflects this.

The single most important decision

Make tenant ID a first-class concept in every layer, from day one. Every row has it. Every query filters on it. Every cache key includes it. Every log line includes it. If you bolt this on later, it's the most painful retrofit in SaaS.

Row-level security is not optional

Application-layer tenant filtering is great, but it's one bug away from a cross-tenant data leak. Use the database's RLS primitives (Postgres is excellent here). Belt and suspenders.

Noisy neighbors

On shared infra, one tenant will eventually run a report that crushes everyone else. Plan for it: per-tenant rate limits, connection pools with caps, and queue priorities. It's cheaper than a migration.

The takeaway

Most SaaS should start shared-database, with bulletproof tenant-scoping and RLS, and evolve to isolated databases only when a specific customer segment demands it. That's what our SaaS Platform ships with as the default — and upgrading to stronger isolation is a config, not a rewrite.