Cosmos DB - Container Copy Features

Question

Cosmos DB - Container Copy Features

Kaushik Dutta 265

Hello Team,

I wanted to know about the current state of the "Container Copy" features in Cosmos DB. Is it in General Available state or in Preview?

Is it available for cross-subscription data copy process? Is this a good feature to use for bulk data copy activity from one env. to another env during environment refresh activities?

Also, in this regards, what will be the best solution to adopt if we need to perform bulk data copy from Production Cosmos Container to a lower environment Cosmos container in least amount of time with minimal cost?

Thanks,

Kaushik

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Himaja Y 545 Microsoft External Staff Moderator

Hi @Kaushik Dutta ,

Thank you for reaching out to the Microsoft Q&A.

Azure Cosmos DB Container Copy can be useful for data migration scenarios, but before adopting it, verify whether the feature is currently General Availability (GA) or still in Preview, as this affects supportability and production readiness.

For large-scale environment refreshes (Production → Lower Environment), the recommended approach is Azure Data Factory (ADF) Copy Activity. It supports cross-subscription data movement, scales well for bulk data transfers, and provides better control over performance and cost.

Recommendation: If your goal is to copy a large Cosmos DB container in the shortest time with minimal cost, use Azure Data Factory with parallel copy settings and temporarily increase RU/s during the migration window. This is the most commonly recommended and reliable approach for enterprise-scale refresh activities.

If refreshes are frequent, consider a Change Feed-based replication solution instead of performing full copies each time.

Kaushik Dutta 265 Reputation points

2026-09-15T15:18:19.2066667+00:00

Thank you for your help and support on this topic.

Regarding your reponse to use ADF for data migration from Prod to lower env in Cosmos DB, we are doing it in a similar way. One of our Container in Prod has 20 milion records and that needs to be migrated fully in lower Env. Our ADF copy activity is taking more than 12 hours to copy. How this can be optimised in order to reduce the time? (this is huge time).

For your reference, in ADF settings are

Maximum DIU is set as Auto and Degree of parallelism is set to Auto.

In Cosmos DB - the Source and Target Throughput is set to AutoScale, scaling between 900 RU/s to 9000 RU/s.

It would be great help if I can get some guidance on this as the current process is taking too much time.

Thanks,

Kaushik
Himaja Y 545 Reputation points Microsoft External Staff Moderator

2026-09-16T14:42:47.54+00:00
Hi @Kaushik Dutta ,

Thank you for the update.

For a container with 20 million records, the 12+ hour copy duration is most likely limited by the available RU/s throughput rather than the ADF settings.

To reduce the copy time:

Temporarily increase source and target Cosmos DB RU/s during the migration window.

Check for 429 (throttling) events, as these indicate the copy is waiting for available throughput.

Verify that data is evenly distributed across partitions to allow parallel processing.

Continue using ADF with parallel copy enabled, but ensure the throughput is sufficient to support the workload.

If environment refreshes are frequent, you may also consider Change Feed-based replication instead of performing a full copy each time.

Could you share the average document size and whether you are seeing any 429 throttling during the copy? This will help identify the primary bottleneck.
Kaushik Dutta 265 Reputation points

2026-09-16T14:59:54.2333333+00:00

Hello,

Thank you so much for your response and your recommendations.

Regarding document size - its approx 10KB, and yes, we are seeing 429 error (throttling) during the migration time - with 10K throttled request (429 errors) initial 1 hour and then average 5K throttled request for the next 12 hours.

In my target Cosmos container the autoscale max is set as 9000 RU/s.
Himaja Y 545 Reputation points Microsoft External Staff Moderator

2026-09-16T17:37:08.3266667+00:00
Hi @Kaushik Dutta ,

Thank you for sharing the details.

The sustained 429 responses confirm that the target container is exceeding its available throughput. With autoscale capped at 9,000 RU/s, Azure Data Factory must retry throttled writes, which increases the overall migration time.

For faster migration, temporarily increase the target container’s maximum RU/s, monitor Normalized RU Consumption and 429 requests, and scale it back after the copy completes. Keep DIU and parallel copies on Auto initially.

If increasing RU/s is not possible, reduce writeBatchSize to around 1000 and lower parallelCopies. This should reduce throttling, but the migration may take longer.

References:

https://learn.microsoft.com/en-us/azure/cosmos-db/troubleshoot-request-rate-too-large?tabs=resource-specific

https://learn.microsoft.com/en-us/azure/data-factory/copy-activity-performance-troubleshooting

https://learn.microsoft.com/en-us/azure/data-factory/connector-troubleshoot-azure-cosmos-db
Kaushik Dutta 265 Reputation points

2026-09-17T08:03:22.1933333+00:00

Thank you so much for your response. We will try this at our end and share our findings.

I have aceepted this answer.
Himaja Y 545 Reputation points Microsoft External Staff Moderator

2026-09-17T10:23:55.8666667+00:00

Hi @Kaushik Dutta ,

Thank you for the update. Please proceed with the testing and share your findings at your convenience. We will review the results and continue assisting as needed.

Answer 2

Container copy in Azure Cosmos DB is currently Preview.

Supported scope from the provided documentation:

It is used to copy data within an Azure Cosmos DB account.
For API for NoSQL, it supports container copy jobs in Azure Cosmos DB accounts.
For API for MongoDB, it supports offline collection copy within the same Azure Cosmos DB for MongoDB account.
For API for Apache Cassandra, it supports offline table copy within the same Azure Cosmos DB for Apache Cassandra account.

The provided documentation does not describe cross-subscription container copy support. Based on the documented scope, this feature is positioned for intra-account copy scenarios such as:

copying all items from one container to another
changing partition key
updating unique keys
renaming a container or database
adopting features supported only for new containers

For bulk copy during environment refresh, whether it is a good fit depends on the API and copy mode:

API for NoSQL supports online and offline copy patterns.
MongoDB and Cassandra APIs in the provided documentation describe offline copy.
For offline copy, writes to the source should be stopped before starting the job. Otherwise, updates and deletes after the job starts might not be captured, and the target can end up with duplicate or missing data.

If the goal is the least amount of time, the documented performance guidance is:

Create the target container/table/collection first with the required settings.
Run the copy job using Azure CLI or Azure portal.
Set the target throughput to at least two times the source throughput.
Be aware that copy rate is affected by:
- source throughput
- target throughput
- server-side compute allocated by the platform
The default SKU provides two 4-vCPU, 16-GB server-side instances per account.

If the goal is minimal cost, the documentation provided does not give a separate recommended low-cost alternative for cross-environment or cross-subscription bulk copy. It only documents container copy behavior and prerequisites. For NoSQL online copy, there is also an RU surcharge on replace and delete operations on the source account, ranging from 50-100% on top of base write RU charges by document size.

Practical guidance supported by the documentation:

Use container copy when the source and destination fit the documented scope and when creating a new target container with different settings is required.
For the fastest documented copy progress, provision the destination with higher throughput, especially at least 2x the source.
For offline copy, stop source activity first to avoid data inconsistency.
For NoSQL online copy, enable continuous backup and All versions and deletes change feed mode on the source account, then wait at least 30 minutes after enabling the capability before creating the online copy job.

References: