Of Django, PostgreSQL schemas, and your multi-million dollar idea
summary
Django plus PostgreSQL schemas works but with concrete tradeoffs: packages like django-tenant-schemas and django-tenants implement a custom DB backend, migrate hooks and routers; tenant creation is slow because each new schema runs migrations unless you clone a provisioning schema; migrations and backups slow as tenants grow; a rough capacity formula is scary number: 1_000_000 / tables_per_tenant (≈10,000 tenants at 100 tables); users, sessions and shared-vs-private model placement cause real leakage risks; sharding by mapping schemas to physical databases is possible but nontrivial.
AI-written summary · about
chapters (16)
- 0:00Intro
- 3:08Database approaches
- 4:11PostgreSQL schemas in Django
- 6:22Tenants, schemas and models
- 9:11Where to put users?
- 10:47Moving models between schemas
- 12:04Tenant creation is slow
- 12:55You know what else is slow?
- 13:43Zero downtime deployments
- 14:53Other middle-term challenges
- 16:00Tables, tables and more tables
- 18:22Why don't we shard?
- 20:38The moment of chaos
- 21:22Is multi-tenancy through schemas de facto wrong as a choice?
- 22:11Should you change your database architecture to something other than schemas?
- 23:34And that's it!
related talks
30mMulti-tenancy strategies with Django+PostgreSQL
28mA thousand Djangoes within (or Django multi-tenant)
31mSpace Django: Migrating and Redesigning a Database while Hunting for Satellites.
21mMultitenant, the Hell of Migrations
33mPeaceful Django Migrations with Efe Öge
23mDjango with PostgreSQL superpowers
52mRe-engineering Postgres for Millions of Tenants
22mDjango with PostgreSQL superpowers