Multitenant Web Applications with Phoenix
summary
Shows a concrete Phoenix + Ecto implementation that isolates each client in a separate Postgres schema using Triplex to create/rename/drop tenants, a Plug that assigns the tenant from URL, and Ecto calls using the Ecto prefix (Triplex.prefix) to query the right schema. Migrations live in a tenant directory and Triplex applies them to all tenants; this setup works for ~30 tenants in production but migrations become slow at scale and cross-schema joins are awkward, while single-instance replication and dump/restore per tenant are trivial.
AI-written summary · about
chapters (7)
- 0:00Introduction
- 2:06Multi-tenancy overview
- 7:07Phoenix request lifecycle
- 11:21Multi-tenancy with Triplex
- 16:33Migrations and tenants
- 18:21Benefits and limits
- 21:44Q&A
related talks
25mMultitenancy with Rails
52mMultitenancy: cost-efficient and scalable patterns for Software-as-a-Service
28mDivide and Conquer: Multi-tenancy in Postgres
51mMultitenant Mystery Only Rockers in the Building
30mMulti-tenancy strategies with Django+PostgreSQL
52mRe-engineering Postgres for Millions of Tenants
21mMultitenant, the Hell of Migrations
29mHOW TO SAFELY SPLIT YOUR MULTI-TENANT APPLICATION (BASED ON REAL EXAMPLES!)