Multitenant applications: how and why
summary
Compares three concrete multitenancy patterns with runnable Django code: customer_id in every table (single shared schema, simple queries but manual filtering risk), per-customer databases (uses Django routers or threadlocal DB selection), and a single Postgres instance with per-tenant schemas using django-tenant-schemas and Postgres schemas. Shows how search_path is set, migrations run once per schema (scale concern), cross-schema unions need UUIDs to avoid ID clashes, and warns about thousands-of-tenants limits and migration risks.
AI-written summary · about
chapters (10)
- 0:00Intro
- 0:32Who am I
- 1:53Context
- 4:09Structure
- 6:40Salesforce example
- 8:12Multiple databases
- 10:05Is this really multitenant
- 10:34Single database
- 12:32Django Schemas
- 16:48Upsides
related talks
21mMultitenant, the Hell of Migrations
28mDivide and Conquer: Multi-tenancy in Postgres
46mMaking an Application Multitenant Without Annoying Developers
31m"Notes on Over-Engineering: A Project Post-Mortem"
25mMulti-Tenancy Architecture Lessons Learned
24mImplementing multi-tenancy in a Laravel app
31mSaaS Migration: Moving From Single-Tenant to Multi-Tenant on AWS
44mHello Multitenancy World!