Share via

Can't increase the Azure CosmoDB for Postgresql storage

Denislav Tsonev 20 Reputation points
2026-03-31T09:41:27.7633333+00:00

Storage increased from 256 GB to 512 GB, ARM shows provisioningState: Succeeded, but default_transaction_read_only = on is still active and the coordinator node disk does not

appear to have been physically resized

  • Root cause suspicion: Original deployment was manually cancelled mid-flight, leaving the node-level disk resize in an inconsistent state
  • Impact: Production database is in read-only mode
Azure Cosmos DB
Azure Cosmos DB

An Azure NoSQL database service for app development.

0 comments
Answer accepted by question author
  1. Manoj Kumar Boyini 11,600 Reputation points Microsoft External Staff Moderator
    2026-03-31T10:22:21.0066667+00:00

    Hi Denislav Tsonev,

    Thank you for your patience. Although the storage was successfully scaled from 256 GB to 512 GB, the cluster remained in read‑only mode because the standby node had not yet fully caught up with the primary. This is an automatic platform protection to maintain data consistency.

    The operation was not stuck, but progressing slowly due to the D2 (2 vCore) VM size, which is not ideal for production workloads especially during WAL replay and recovery. Additionally, an autovacuum process started while disk space was nearly full, increasing I/O pressure.

    Increased the vCores from 2 to 4

    Stopped the autovacuum process

    Allowed the standby node to catch up, after which failover completed successfully

    Once this completed, the cluster exited read‑only mode and write access was restored. You have confirmed the cluster is now working as expected.

    Recommendation: Monitor disk I/O closely. If utilization frequently reaches 80–100%, consider upgrading to a configuration with higher IOPS capacity, not just larger storage size.

    Hope this helps, Please let us know if you have any questions and concerns.

    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Sina Salam 28,361 Reputation points Volunteer Moderator
    2026-03-31T13:35:44.2866667+00:00

    Hello Denislav Tsonev,

    Welcome to the Microsoft Q&A and thank you for posting your questions here.

    I understand that you can't increase the Azure CosmoDB for Postgresql storage.

    For a best practice resolution based on Microsoft documentation and your scenario. Follow the below steps in order to resolve the issue:

    1. Because the ARM deployment succeeded but disk didn't grow, you must confirm storage on the coordinator + worker nodes using Azure portal: Go to Scale > Storage per node. If the value is still 256 GB on coordinator, the disk resize never executed. - https://dori-uw-1.kuma-moon.com/en-us/azure/cosmos-db/postgresql/howto-scale-grow
    2. Azure Cosmos DB for PostgreSQL uses coordinated scaling: Worker nodes and coordinator must resize together If a node fails during resize, cluster remains in partially updated state - https://dori-uw-1.kuma-moon.com/en-us/azure/cosmos-db/postgresql/howto-scale-grow To fix: Perform the following in exact order:
    3. In some storage enlargement cases, a restart is required for the instance to detect the newly resized underlying disk. This is behavior also documented in Azure Database for PostgreSQL flexible server during certain scale operations. - https://dori-uw-1.kuma-moon.com/en-us/azure/postgresql/scale/how-to-scale-storage-size Even though this is CosmosDB‑Postgres, the underlying OS/disk detection logic behaves similarly.
    4. Verify that storage usage is no longer 100% by Run SQL command: SELECT pg_size_pretty(pg_database_size(current_database())); If storage remains at threshold, Postgres will remain in read‑only mode.
    5. If still read‑only: Azure Expert must repair the failed deployment. This matches exactly the moderator response requesting private details. In real-world terms, Azure Support must:
      • Inspect failed VM/disk resize actions
      • Reattach or re-provision the coordinator disk
      • Repair the cluster state in the Citus control plane
      This is not user-fixable, based on service architecture.
    6. This is a new Mandatory Recommendation for future purposes: Migrate to Supported Service. Because Azure Cosmos DB for PostgreSQL is retiring, the official guidance is to move to Azure Database for PostgreSQL – Flexible Server (with Elastic Cluster) for Citus workloads - https://dori-uw-1.kuma-moon.com/en-us/azure/cosmos-db/postgresql/howto-scale-grow). This eliminates the risk of stuck scaling operations at any point.

    I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

    Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.