Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Important
Azure Cosmos DB for PostgreSQL is no longer supported for new projects. Don't use this service for new projects. Instead, use one of these two services:
Use Azure Cosmos DB for NoSQL for a distributed database solution designed for high-scale scenarios with a 99.999% availability service level agreement (SLA), instant autoscale, and automatic failover across multiple regions.
Use the Elastic Clusters feature of Azure Database For PostgreSQL for sharded PostgreSQL using the open-source Citus extension.
The size of a cluster, both number of nodes and their hardware capacity, is easy to change. However you still need to choose an initial size for a new cluster. Here are some tips for a reasonable choice.
Use-cases
Azure Cosmos DB for PostgreSQL is frequently used in the following ways.
Multi-tenant SaaS
When migrating to Azure Cosmos DB for PostgreSQL from an existing single-node PostgreSQL database instance, choose a cluster where the number of worker vCores and RAM in total equals that of the original instance. In such scenarios we have seen 2-3x performance improvements because sharding improves resource utilization, allowing smaller indices etc.
The vCore count is actually the only decision. RAM allocation is currently determined based on vCore count, as described in the compute and storage page. The coordinator node doesn't require as much RAM as workers, but there's no way to choose RAM and vCores independently.
Real-time analytics
Total vCores: when working data fits in RAM, you can expect a linear performance improvement on Azure Cosmos DB for PostgreSQL proportional to the number of worker cores. To determine the right number of vCores for your needs, consider the current latency for queries in your single-node database and the required latency in Azure Cosmos DB for PostgreSQL. Divide current latency by desired latency, and round the result.
Worker RAM: the best case would be providing enough memory that most the working set fits in memory. The type of queries your application uses affect memory requirements. You can run EXPLAIN ANALYZE on a query to determine how much memory it requires. Remember that vCores and RAM are scaled together as described in the compute and storage article.
Next steps
- Scale a cluster
- Learn more about cluster performance options.