A thousand Djangoes within (or Django multi-tenant)
summary
Defines an active tenant as the runtime context used for queries, URL reversing, cache keys and management commands and shows three concrete database patterns: isolated databases per tenant (one DB alias per tenant, DB routers required), shared database with tenant column (inject tenant filters via managers or defaults, heavy test coverage needed) and Postgres schemas (semi‑isolated, requires custom DB backend, search_path and schema‑aware migrate). Also details middleware routing from domain/session, use of asgiref/threadlocals for async, tenant‑aware cache keys, file storage and Celery tasks and warns migrations and channels need extra work.
AI-written summary · about
chapters (16)
- 0:00Introduction and speaker intro
- 1:31Why multi-tenancy matters
- 3:16What is multi-tenancy?
- 6:02Active tenant concept
- 8:50Three architectural choices
- 9:10Users and tenants relationship
- 10:36Database architecture approaches
- 12:41Shared database approach
- 15:30Semi-isolated database approach
- 17:58Choosing the right approach
- 18:18Tenant routing in requests
- 21:26Framework scope beyond core
- 21:47Management commands and files
- 24:18Caching and async tasks
- 25:01Celery tasks and channels
- 26:47Packages and closing remarks
related talks
30mMulti-tenancy strategies with Django+PostgreSQL
24mOf Django, PostgreSQL schemas, and your multi-million dollar idea
31m"Notes on Over-Engineering: A Project Post-Mortem"
21mBuilding maintainable Django projects: the difficult teenage years
30m"Using Multiple Databases in Django Applications"
01h 06mEffective Django
24mEvolving Django: What We Learned
26mDjango at