Multi-tenant SaaS apps made simple on Azure Cosmos DB for PostgreSQL
summary
Explains how Azure Cosmos DB for PostgreSQL (Citus extension) actually distributes rows into shards, requiring a distribution key and giving concrete limits: 100,000 tenants per 16 vCPU node for row-sharding, ~4–5k per node for schema-per-tenant and ~100 per node for database-per-tenant. Describes coordinator vs worker nodes, multi-tenant monitoring (queries and CPU per tenant), distributed/reference/local tables, online rebalancing and tenant isolation to eject noisy neighbors, and practical tradeoffs for reads, writes and backfilling.
AI-written summary · about
chapters (14)
- 0:00Intro
- 1:16Multi-tenant SaaS
- 9:36Row based vs Schema Based vs Database Sharding
- 18:27Azure Cosmos DB for PostgreSQL
- 20:22Terminology
- 24:11Pick a distribution key
- 29:19Identify types of tables
- 30:22Distributed Tables
- 33:09Reference Tables
- 34:31Local tables
- 35:21Modify your application
- 36:50Monitor - upcoming in Citus 11.3
- 40:15Isolate tenant
- 41:04Rebalance
related talks
27mMulti-tenant Saas apps made simple on Azure Cosmos DB for PostgreSQL
18mBuilding Performant Data Architecture for Multi-Tenant SaaS Apps
14mEasier Queries for Multi-Tenant SaaS Apps
13mHow to do Data Modeling for Distributed Postgres in Azure Cosmos DB
14mBest Practices for Building Multi-Tenant Applications on Azure Cosmos DB
08mFoundations of Distributed PostgreSQL with Citus
24mCitus from the Customer eyes
59mLearn Live: Model data for Azure Cosmos DB for PostgreSQL