My CosmosDB is self-scaling 200x above documented requirements

Hello Trevor Christman,

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

I understand that your CosmosDB is self-scaling 200x above documented requirements.

This is a known issue by Microsoft documentation. Therefore, you will have to observe value points to shared-throughput database behavior, historical/internal scaling state, service-side shared-throughput partition management, or another account-specific backend factor that must be validated by Microsoft Internal - Cosmos DB engineering. - https://learn.microsoft.com/en-us/azure/cosmos-db/concepts-limits, https://learn.microsoft.com/en-us/azure/cosmos-db/set-throughput

What you can do from your side is to:

Stop running the large active container inside a shared-throughput autoscale database.

• Create a new Azure Cosmos DB container with dedicated container-level autoscale throughput.
• Use the same partition key only if it is already well distributed; otherwise create the new container with a better partition key or hierarchical partition key design.
• Migrate the data from the shared-throughput container to the new dedicated-throughput container.
• Cut over the application to the new container after validating item count, indexing policy, queries, RU consumption, latency, and 429 rate.
• Since PCS is attending to this case, there will be a perfect solution. If there is delay, open an Azure Support case via your portal with the SharedThroughputSplit Activity Log entries and request Cosmos DB Product Group confirmation of the exact backend factor that raised the minimum autoscale max RU/s floor.

This is the only advice because Microsoft recommends container-level throughput for most workloads, and Microsoft explicitly warns that shared database throughput can lead to unpredictable performance and scale behavior when containers share capacity. A shared database container also cannot be converted in place to dedicated throughput; the data must be moved to a container created with the desired throughput model. - https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-provision-database-throughput

After the large active container is moved to dedicated autoscale throughput, the workload is isolated from the shared database’s scaling behavior. The remaining question, why the existing shared database is locked at about 715k/804k max RU/s, must be handled by Azure Support. Of course, that actual minimum RU/s can vary depending on account configuration. - https://learn.microsoft.com/en-us/azure/cosmos-db/concepts-limits, https://learn.microsoft.com/en-us/azure/cosmos-db/set-throughput

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

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

Hi @Trevor Christman

Your database is using shared throughput, the active container has grown to approximately 2.1 TB, and we can see recurring SharedThroughputSplit operations alongside a significant increase in the minimum configurable throughput.

Microsoft documentation also notes that shared database throughput is not recommended for most large or growing workloads, as scaling a large container can trigger repartitioning and other scaling behaviors across the shared-throughput database.

While these observations suggest that the increasing throughput floor is related to how Cosmos DB is managing and scaling the shared-throughput database, the public documentation does not fully explain the current minimum value of 804,000 RU/s. We are reviewing this behavior further to determine whether it is driven by partition-layout requirements, throughput history, or another service-level scaling mechanism.

In the meantime, could you confirm whether migrating the active container to dedicated throughput is a possible option for your workload? Microsoft recommends container-level throughput for large production workloads because it provides more predictable scaling behavior and performance isolation.

Reference:
https://learn.microsoft.com/en-us/azure/cosmos-db/set-throughput#set-throughput-on-a-database

Welcome to Microsoft Q&A

Hello @Trevor Christman , I hope you are doing well.

Operations shown in the Activity Log indicate that Azure Cosmos DB is performing physical partition splits. During these operations, the service may automatically increase the minimum throughput to maintain the required RU/s per physical partition. If enough physical partitions are created over time, the minimum provisioned throughput can become significantly higher than the original calculation based solely on data size.

To better understand why your minimum throughput has increased to 715,000 RU/s, could you confirm the following?

Is this a shared throughput database or a dedicated throughput container?

Which API are you using (NoSQL, MongoDB, Cassandra, etc.)?

Has the data volume or ingestion rate changed significantly during the last 30 days?

• Approximately how many containers are sharing the database throughput?

You can also review the Metrics blade for your Cosmos DB account and compare Physical Partition Count, Normalized RU Consumption, and Storage over the same period. This can help determine whether the throughput increases correspond to partition growth rather than workload demand.

If the physical partition count has increased substantially beyond what would normally be expected for your data size and workload, that would suggest the service behavior should be reviewed further.

References:

Azure Cosmos DB partitioning overview

Azure Cosmos DB provisioned throughput and autoscale

If my answer helped you, please consider marking it as accepted. This helps others in the community find similar solutions.