Divide and Conquer: Multi-tenancy in Postgres
summary
Compares concrete multi-tenant architectures and tradeoffs: one VM per tenant gives maximal isolation and per-tenant tuning but high operational cost; partitioned tables + row‑level security (RLS) gives central reporting and lower overhead but forces cluster‑wide upgrades and shared performance; sharding via Citus or custom partition placement enables geographic distribution and per‑shard scaling. Recommends picking the simplest architecture that balances performance, isolation, HA, manageability and cost; uses a bakery example to show choosing partitioning+RLS for a few franchises.
AI-written summary · about
chapters (6)
- 0:00Introduction
- 1:06Multi-Tenancy
- 2:30Using a cake bakery to set the scene
- 4:35Multi-tenant Options
- 21:32How do you choose?
- 26:16Conclusions
related talks
30mMulti-tenancy strategies with Django+PostgreSQL
52mRe-engineering Postgres for Millions of Tenants
52mMultitenancy: cost-efficient and scalable patterns for Software-as-a-Service
18mBuilding Performant Data Architecture for Multi-Tenant SaaS Apps
25mData-intensive PostgreSQL: Three ways to scale
25mMultitenancy with Rails
25mSaaS on Rails on PostgreSQL
25mMultitenant applications: how and why