System Design

Multi-tenancy Study Portal

Seven tenancy models from shared tables to deployment stamps: where the wall between tenants lives, pros and cons, who uses each, and how to choose
Flash Cards Practice
System Design / Multi-tenancy / Key takeaways

Multi-tenancy · Key takeaways

1 min read
Senior14 min read
Rapid overview

Key takeaways

  • The design question is where the wall between tenants lives; further out is stronger and costlier.
  • Pool is the default; add row-level security so a missed filter is not a breach.
  • RLS failures come from tenant context on pooled connections and owner/superuser bypass, not from the policy text.
  • Schema per tenant suits tens to hundreds of tenants; the catalogue and migrations hurt at thousands.
  • Database per tenant needs a highly available tenant catalogue and fleet automation.
  • Deployment stamps isolate compute, releases and region, not just data.
  • Tiered pool + silo turns isolation into a price tier; tenant sharding is about capacity, not isolation.
  • A header or path tenant selector is fine only when checked against the user's memberships.
  • Keep the tenant wall in the data layer and permissions above it: a forgotten permission check then over-shares inside one tenant, never across tenants.

See also