Multi-tenant Postgres: Where Each Design Hits a Wall
24 November
Every multi-tenant system on Postgres picks one of three isolation models: a shared table keyed by tenant_id (often guarded by Row-Level Security), a schema per tenant, or a database per tenant. The trade-offs are easy to recite in the abstract - and much harder to feel until one of them quietly hits a wall in production.
Drawing on real deployments, this talk walks each model to its limit. For the shared model: RLS ergonomics and the planner behavior that can surprise you. For schema-per-tenant: the honeymoon, then the catalog, planning-time, and pg_dump/autovacuum pressure that builds as tenant count climbs. For database-per-tenant: the strongest isolation, paid for in connections, backups, and operational sprawl. We'll also look at the hybrid "pods of tenants" pattern that large SaaS platforms tend to converge on.
The result is a decision framework grounded in where each design breaks - so you choose the model that hits its wall after your growth plan, not before.
Key takeaways: the practical scaling limits of each isolation model; how to use RLS without paying for it twice; why schema-per-tenant degrades and roughly when; and a grounded framework for choosing and evolving your tenancy model.