|
| 1 | +--- |
| 2 | +title: Change partition key |
| 3 | +titleSuffix: Azure Cosmos DB |
| 4 | +description: Change partition key in Azure Cosmos DB for NOSQL API. |
| 5 | +author: richagaur |
| 6 | +ms.author: richagaur |
| 7 | +ms.service: cosmos-db |
| 8 | +ms.topic: conceptual |
| 9 | +--- |
| 10 | +# Changing the partition key in Azure Cosmos DB (preview) |
| 11 | + |
| 12 | +[!INCLUDE[NoSQL](../includes/appliesto-nosql.md)] |
| 13 | + |
| 14 | +In the realm of database management, it isn't uncommon for the initially chosen partition key for a container to become inadequate as applications evolve. It can result in suboptimal performance and increased costs for the container. Several factors contributing to this situation include: |
| 15 | + |
| 16 | +- [Cross partition queries](how-to-query-container.md#avoid-cross-partition-queries) |
| 17 | +- [Hot partitions](troubleshoot-request-rate-too-large.md?tabs=resource-specific#how-to-identify-the-hot-partition) |
| 18 | + |
| 19 | +To address these issues, Azure Cosmos DB offers the ability to seamlessly change the partition key using the Azure portal. |
| 20 | + |
| 21 | +## Getting started |
| 22 | + |
| 23 | +To change the partition key of a container in Azure Cosmos DB for the NoSQL API using the Azure portal, follow these steps: |
| 24 | + |
| 25 | +1. Navigate to the **Data Explorer** in the Azure Cosmos DB portal and select the container for which you need to change the partition key. |
| 26 | +2. Proceed to the **Scale & Settings** option and choose the **Partition Keys** tab. |
| 27 | +3. Select the **Change** button to initiate the partition key change process. |
| 28 | + |
| 29 | + |
| 30 | + |
| 31 | +## How the change partition key works |
| 32 | + |
| 33 | +Changing the partition key entails creating a new destination container or selecting an existing destination container within the same database. |
| 34 | + |
| 35 | +If creating a new container using the Azure portal while changing the partition key, all configurations except for the partition key and unique keys are replicated to the destination container. |
| 36 | + |
| 37 | + |
| 38 | + |
| 39 | +Then, data is copied from the source container to the destination container in an offline manner utilizing the [Intra-account container copy](../container-copy.md#how-does-container-copy-work) job. |
| 40 | + |
| 41 | +>[!Note] |
| 42 | +> It is recommended to stop all updates on the source container before proceeding to change the partition key of the container for entire duration of copy process to maintain data integrity. |
| 43 | +
|
| 44 | +Once the copy is complete, you can start using the new container with desired partition key and optionally delete the old container. |
| 45 | + |
| 46 | + |
| 47 | +## Limitations |
| 48 | +- By default, two server-side compute instances, each with 4 vCPUs and 16 GB of memory, are allocated to handle the data copy job per account. The performance of the copy job relies on various [factors](../container-copy.md#factors-that-affect-the-rate-of-a-container-copy-job). To allocate higher SKU server-side compute instances, please reach out to Microsoft support. |
| 49 | +- Partition key modification is supported for containers provisioned with less than 1,000,000 RU/s and containing less than 4 TB of data. For containers with over 1,000,000 provisioned throughput or more than 4 TB of data, please contact Microsoft support for assistance with changing the partition key. |
| 50 | +- Changing partition key isn't supported for accounts with following capabilities. |
| 51 | + * [Disable local auth](../how-to-setup-rbac.md#use-azure-resource-manager-templates) |
| 52 | + * [Merge partition](../merge.md) |
| 53 | +- The feature is currently supported only in the documented [regions](../container-copy.md#supported-regions). |
| 54 | + |
| 55 | +## Next steps |
| 56 | + |
| 57 | +- Explore more about [container copy jobs](../container-copy.md). |
| 58 | +- Learn further about [how to choose a partition key](../partitioning-overview.md#choose-partitionkey). |
0 commit comments