หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
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.
For existing Azure Cosmos DB for PostgreSQL deployments only, there are three steps involved in building scalable apps. New projects must use one of the alternative services listed above and should not follow the steps below.
- Classify your application workload. Common workloads where Azure Cosmos DB for PostgreSQL shines include:
- Multitenant SaaS → tenant-isolated schemas or shard keys
- Microservices → service-aligned distributed tables
- Real-time operational analytics → co-located distributed data
- High-throughput OLTP → row-based sharding with a high-cardinality key
- Based on the workload, use schema-based sharding or identify the optimal shard key for the distributed
tables (for example, shard by
tenant_idfor a multitenant SaaS app so that all rows for a tenant are co-located; expected result: queries scoped to a tenant are routed to a single shard). Classify your tables as reference, distributed, or local. - When using row-based sharding, update the database schema and application queries to make them go fast across nodes.
Success check: After completing these steps, tenant- or shard-key–scoped queries consistently target a single worker node and show stable low latency under load.
Next steps
Before you start building a new app, you must first review a little more about the architecture of Azure Cosmos DB for PostgreSQL.