Best Practices for Building Multi-Tenant Applications on Azure Cosmos DB
summary
Two clear architectures: one database account per tenant gives per-tenant RU isolation, independent geo replication and customer‑managed keys but costs more; partition key per tenant keeps costs low and makes cross‑tenant queries simple but risks noisy neighbors and hits the 20 GB logical partition limit. Remedies include synthetic partition keys to shard large tenants or hierarchical partition keys with up to three levels (top level must have high cardinality). Hybrid setups and autoscale/partition merge reduce tradeoffs.
AI-written summary · about
chapters (9)
- 0:00Multi-tenant Azure Cosmos DB intro
- 1:08Design considerations for multi-tenancy
- 2:55Isolating tenants by account
- 4:39Security and regional isolation
- 5:46Partition key per tenant
- 8:57B2C partition key isolation
- 10:43Handling tenant skew and costs
- 12:30Advanced partitioning with hierarchy
- 13:12Summary and future work
related talks
46mDesign and build multi-tenant SaaS apps at scale with Azure Cosmos DB
44mMulti-tenant SaaS apps made simple on Azure Cosmos DB for PostgreSQL
18mBuilding Performant Data Architecture for Multi-Tenant SaaS Apps
27mMulti-tenant Saas apps made simple on Azure Cosmos DB for PostgreSQL
58mKeeping the Noisy Neighbors Happy
14mEasier Queries for Multi-Tenant SaaS Apps
01h 00mCost cutting strategies for Azure Cosmos DB
08mOptimize for the Best Cost and Performance for Azure Cosmos DB NoSQL API