Re-engineering Postgres for Millions of Tenants
summary
Nile modifies Postgres with an extension, a Go gateway, and a custom storage manager that puts tenant partitions on per-tenant table spaces backed by object storage via Slate DB on S3. Queries route by tenant ID to a Postgres 15 instance, planner rewrites switch OIDs to per-tenant partitions, and cross-tenant queries use inherited FDWs + union all. Tenant moves freeze, copy WAL slices, detach/reattach partitions; catalog IDs limit scale to about 16 million tenants.
AI-written summary · about
chapters (15)
- 0:00Introduction and thank you
- 1:38Multi-tenant applications overview
- 4:28Isolated vs pooled tenant models
- 8:47Sharding for data locality
- 10:15Nile’s tenant isolation architecture
- 13:28Storage layer and table spaces
- 17:24Tenant creation flow
- 21:37Querying tenant data
- 24:06Cross-tenant query architecture
- 30:06Moving tenants between servers
- 34:19Benefits and ROI of the architecture
- 37:07Challenges and limitations
- 40:21Future improvements and ideas
- 43:55Summary and key takeaways
- 44:16Q&A session
related talks
28mDivide and Conquer: Multi-tenancy in Postgres
25mData-intensive PostgreSQL: Three ways to scale
43mJust Use Postgres.
30mMulti-tenancy strategies with Django+PostgreSQL
13mBuilding reliable infrastructure with Postgres
25mSaaS on Rails on PostgreSQL
26mPartitioning your Postgres tables for 20x better performance
51mIdentity at Scale; How Okta uses Postgres