what are the risks with deleting Cosmos Replica?

Jesse 0 Reputation points
2026-09-04T02:31:42.9966667+00:00

Hi,

I've got an Azure Cosmos DB account running a single container. The db is quite large and we're being charged double in storage costs as we have our main replica, then a readonly replica in practically the same region. We want to look at deleting the read only region and keep our main single read/write region.

I can't find any info on possible risks, the do's and don'ts for deleting a replica. Is there any risk of data loss, is there a way to undo the delete if it does impact the service?

I understand there might be intermittent downtime due to internal routing but we're not worried about that, we just want to know if our data is safe.

Azure Cosmos DB
Azure Cosmos DB

An Azure NoSQL database service for app development.

0 comments No comments

Answer accepted by question author
Marcin Policht 105.8K Reputation points MVP Volunteer Moderator
2026-09-04T03:15:12.6833333+00:00

Yep - your data is safe. Deleting a read-only replica region in a single-write Azure Cosmos DB account does not delete the data in the remaining primary region. Each Cosmos DB region maintains its own complete copy of the container, with the data internally replicated within that region. When you remove the secondary region, you are removing that region's copy, while the primary write region and its data remain intact.

Note that the main consequence is loss of regional redundancy. Once you have a single region, a regional outage can no longer be handled by failing over to the second Cosmos DB region. This is the primary risk to consider, rather than data loss caused by removing the replica.

There is no instantaneous undo or rollback button, but the change is reversible in the sense that you can add the removed region back to the Cosmos DB account later. Because your database is large, however, this would not be instantaneous. Cosmos DB must replicate the complete dataset from the remaining region into the newly added region before that region is fully available. Therefore, adding it back is a re-replication operation, not restoration of the old replica.

Operationally, avoid making other account-level changes at exactly the same time as the region removal. For example, active asynchronous throughput-scaling operations can be temporarily paused while the region change completes. Also monitor the account if the portal remains in an Updating or Deleting state for an unusually long period. The removal itself should not affect the integrity of the data in the surviving region.

Also check your application configuration. If your Cosmos DB SDK has the region you are removing explicitly configured as a preferred location, update that configuration so the application does not unnecessarily attempt to connect to the removed region. The SDK can generally fall back to the remaining region, but removing a no-longer-valid preferred location avoids unnecessary connection attempts.


If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Was this answer helpful?

1 person found this answer helpful.

0 additional answers

Sort by: Most helpful

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.