Storage metric is not updated for Azure Cosmos DB for PostgreSQL

Question

Issue Summary:

• Azure Cosmos DB for PostgreSQL single-node cluster storage upgrade from 512GB to 1024GB (last night) shows provisioned capacity correctly in Scale blade and Worker metrics ("1014 GB RAM storage"), but storage_percent metric stuck at 94-95% even after 12+ hours.

Steps Taken:

• Confirmed Scale blade: 1024GB provisioned on single Worker node
• Metrics: 1-min granularity last 30min still 94% used (~486GB used)
• Portal refreshes, Activity Log checked (Scale operation status unclear)
• No data growth observed

Expected: Storage % should drop to ~47-50% post-upgrade

Impact: Critical - Near-full alerts firing incorrectly

Need urgent confirmation if upgrade complete or metric sync issue.

Answer 1

Hello @Pravin,

It seems that you have successfully upgraded the storage for your Azure Cosmos DB for PostgreSQL single-node cluster from 512GB to 1024GB, as confirmed in the Scale blade. However, the storage_percent metric being stuck at 94-95% despite the upgrade could be due to a few factors. The storage_percent metric indicates the percentage of storage used out of the server’s maximum capacity, which includes not just the database files but also temporary files, transaction logs, and server logs.

The storage used by the service may take some time to reflect the changes in the metrics, especially after an upgrade operation. It’s noted that Azure Cosmos DB for PostgreSQL does not provide aggregate metrics for the cluster as a whole, but metrics for multiple nodes can be placed on the same graph.

If the storage_percent metric remains unchanged after a significant amount of time (like 12+ hours), it might be worth checking if there are any ongoing background processes or if the metrics are experiencing a delay in updating. You can also consider reviewing the activity log for any errors or issues related to the scaling operation.

Scale a cluster in Azure Cosmos DB for PostgreSQL

---

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

Answer 2

Hi Pravin,

  As verified together, the storage upgrade to 1024 GB is successfully completed and the cluster health, worker capacity, and database operations all look normal. The higher storage_percent value is due to a temporary telemetry/metrics sync delay rather than actual storage pressure. There is no service impact, and the percentage should automatically correct once monitoring refreshes. For now, any near-full alerts can be treated as false positives while the metrics update.