Azure Cosmos DB for PostgreSQL - Clarification on Restore Behavior and Recommended Migration Approach

RAKSHITHA BAI 0 Reputation points

We have an Azure Cosmos DB for PostgreSQL cluster with the following configuration:

  • 1 Coordinator Node (8 vCores, 512 GB Storage)
  • 7 Worker Nodes (8 vCores, 4 TB Storage per Worker)
  • PostgreSQL 16
  • Citus 12.1

One of the worker nodes was approaching the 2 TB storage limit, so we increased the worker storage from 2 TB to 4 TB on 19 May 2026. Following the storage expansion, we observed a significant degradation in data ingestion performance.

We would appreciate clarification on the following:

  1. During a Point-in-Time Restore, is the restored cluster created using the configuration that existed at the selected restore point, or does it use the current configuration of the source cluster?
  2. If we raise a Microsoft Support request, is there any supported method to restore or migrate the cluster back to a configuration with 2 TB worker storage, considering storage reduction is not supported in-place?
  3. What would be the Microsoft-recommended production-grade migration approach for migrating a large distributed Azure Cosmos DB for PostgreSQL cluster to another cluster while minimizing downtime and ensuring data consistency?

Any guidance on the supported restore behavior and best migration path would be greatly appreciated.

0 comments No comments
Sign in to comment

2 answers

  1. Manoj Kumar Boyini 17,060 Reputation points • Microsoft External Staff • Moderator

    Hi @RAKSHITHA BAI

    Regarding Azure Cosmos DB for PostgreSQL PITR, the restored cluster is created using the current configuration of the source cluster at the time the restore is initiated, while the data is restored to the selected point in time.

    In your case, even if you restore to a point before the storage increase, the restored cluster would still be created with the current 4 TB worker storage configuration.

    Storage reduction from 4 TB back to 2 TB is not supported in-place. Raising a Microsoft Support request is not expected to provide a supported mechanism to restore the cluster to a smaller storage configuration. While it might be possible in certain scenarios depending on the configuration, this is not a tested feature and is not officially supported.

    If a different configuration is required, the recommended approach is to provision a new target cluster and migrate the workload.

    References:

    Please let us know if you have any questions or concerns.

    1. Manoj Kumar Boyini 17,060 Reputation points • Microsoft External Staff • Moderator

      Hi @RAKSHITHA BAI

      I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

    Sign in to comment
  2. Amira Bedhiafi 42,941 Reputation points • MVP • Volunteer Moderator

    Hello Rakshitha !

    Azure Cosmos DB for PostgreSQL PITR is not a configuration rollback/shrink mechanism. The restore process creates a new cluster and Microsoft documents that the restored cluster keeps the original cluster configuration: same node count, vCores, storage size, user roles, PostgreSQL version, and Citus version. Networking settings are not preserved and must be reconfigured after restore.

    https://learn.microsoft.com/en-us/azure/cosmos-db/postgresql/concepts-backup

    Also, storage on coordinator and worker nodes can be increased but cannot be decreased. So even with Microsoft Support, I would not expect an in-place supported reduction from 4 TiB back to 2 TiB on the same cluster.

    https://learn.microsoft.com/en-us/azure/cosmos-db/postgresql/reference-limits

    PITR before the storage scale operation may require support although backups are retained for 35 days, restoring to a point earlier than the latest failover might require a support request, and compute/storage scaling operations use failovers. Since your resize happened on 19 May 2026, this applies directly if you are trying to restore to a point before that operation.

    4 TiB may not improve IOPS over 2 TiB for 8-vCore workers For Azure Cosmos DB for PostgreSQL, both 2 TiB and 4 TiB storage sizes show a maximum of 7,500 IOPS per node. For 7 workers, the aggregate worker IOPS remains 52,500 for both 2 TiB and 4 TiB. So the resize from 2 TiB to 4 TiB increases capacity, but not necessarily write throughput.

    For a production migration , you need to move PostgreSQL workloads from Azure Cosmos DB for PostgreSQL to Azure Database for PostgreSQL Elastic Clusters because Azure Cosmos DB for PostgreSQL is on a retirement path and is no longer recommended for new projects.

    The dedicated migration tool is the preferred path. It runs pre-validation, provisions the target Elastic Cluster, switches the source cluster to read-only, takes per-node snapshots, mounts the disks on the target, applies required metadata/configuration fixes, and then makes the Elastic Cluster the new writable target. Microsoft documents an average write-lock window of around 5–8 minutes, although timing depends on database size, node count, and extensions.

    A read replica plus promotion can help in some DR/read-scale scenarios, but it is asynchronous, can lag by minutes or hours, and is not a guaranteed zero-data-loss migration mechanism. It also does not directly reduce write load on the primary.

    0 comments No comments
    Sign in to comment
Sign in to answer

Your answer