Performance tuning for Azure Cosmos DB
summary
Cosmos DB physical partitions cap at 50 GB / 10,000 RU per physical partition, so bad partition keys blow up cost and scale — ChatGPT drove ~25,000 partitions for ChatGPT (Nov 2023). Use point reads when you have id+partitionKey (about point read=~1 RU vs query~2.3 RU in the demo), prefer direct TCP from .NET SDK 3.x, reuse a singleton client, use change feed + Azure Functions to duplicate by alternative partition key, enable patch operations (id+pk required), computed properties and dedicated gateway caching cut RU and bandwidth.
AI-written summary · about
chapters (21)
- 0:00Cosmos DB performance tuning
- 1:09Physical partitions in Cosmos DB
- 6:50Partition key selection
- 8:12Fixing cross-partition queries
- 10:16Optimizing point read queries
- 11:42Gateway vs Direct modes
- 14:59Dedicated Gateway mode
- 19:15Aggregations in Cosmos DB
- 21:21SDK configuration
- 22:45Stream API serialization
- 24:08DocumentClient best practices
- 26:11Metadata requests
- 27:16Bulk operations optimization
- 28:20Partial document updates
- 30:49Indexing strategies
- 37:51Computed properties
- 39:13Provisioned vs autoscaling vs serverless
- 41:46Reserve capacity
- 42:51Priority-based execution
- 45:03VS Code extension demo
- 49:22Q&A
related talks
48mPerformance tuning for Azure Cosmos DB
01h 00mCost cutting strategies for Azure Cosmos DB
08mOptimize for the Best Cost and Performance for Azure Cosmos DB NoSQL API
01h 03mData Modeling and Partitioning in Azure Cosmos DB
49mSQL Server vs Azure Cosmos DB
46mDesign and build multi-tenant SaaS apps at scale with Azure Cosmos DB
59mPlanet scale or planet fail?
14mHow to achieve good cost/performance with Azure Cosmos DB elasticity