Multi-tenancy strategies with Django+PostgreSQL
summary
Three concrete strategies compete: separate app+db per tenant (strong isolation, expensive, painful at scale); schema-per-tenant or multiple DBs routed by middleware (single codebase, migrations and table‑lock limits bite, connection‑pooling makes connection stateful); and shared tables with tenant_id denormalization plus Django managers (easier querying, biggest risk is forgetting to filter). Postgres row level security and tools like Django tenants and django multi-tenant or Cytus sharding provide safety nets but add operational complexity. Threads, transactions and migrations are the usual failure modes.
AI-written summary · about
chapters (4)
related talks
28mA thousand Djangoes within (or Django multi-tenant)
24mOf Django, PostgreSQL schemas, and your multi-million dollar idea
28mDivide and Conquer: Multi-tenancy in Postgres
14mEasier Queries for Multi-Tenant SaaS Apps
25mMultitenancy with Rails
25mSaaS on Rails on PostgreSQL
52mMultitenancy: cost-efficient and scalable patterns for Software-as-a-Service
21mMultitenant, the Hell of Migrations