Autoscale min RU/s floor driven by historical peak — why is there no bound/reset on the historical peak

Question

Autoscale min RU/s floor driven by historical peak — why is there no bound/reset on the historical peak

Augustine Wu 0 Microsoft Employee

An attempt to lower a container's autoscale max throughput to 35,000 RU/s was rejected with:

The offer should have valid throughput values between 39000 and 100000 inclusive in increments of 1000. Requested throughput 35000 is less than minimum throughput 39000 required to fulfil the consumed storage of ~152 GB.

Analysis

Cosmos DB enforces the autoscale minimum max RU/s as:

MAX(1000, storage_GB × 10, highest_RUs_ever_provisioned ÷ 10)

For this container the 39,000 floor is not explained by current usage:

• Storage: ~152 GB → only ~1,525 RU/s

• Physical partitions: 8 → only ~8,000 RU/s

• Historical peak: the binding factor — the container was previously provisioned to ~390,000 RU/s, and 390,000 ÷ 10 = 39,000.

Cosmos permanently retains this "highest RU/s ever provisioned" high-water mark, so the floor stays at 39,000 even though current storage and partition count are far lower. The error text references "consumed storage" only because that's the generic offer-validation message; the actual driver is the historical scale-up.

Question for the team

Why is there no bound, decay, or reset on this historical high-water mark? If a container's storage and partition count have dropped well below what the peak required, why does the peak continue to dictate the minimum indefinitely — with no way to recompute the floor against current storage/partitions, and no mechanism to reset it short of migrating the data into a brand-new container?

Augustine Wu 0 Reputation points Microsoft Employee

2026-07-27T15:19:54.9+00:00

Thank you @Pilladi Padma Sai Manisha for your suggestions. I have a follow up question. So on our container, and especially this one, I initially thought that maybe it was due to 39 physical partitions too, but by checking azure monitoring metric, we only have 8 physical partitions on this account, would it still help here to merge the partition?
Pilladi Padma Sai Manisha 11,705 Reputation points Microsoft External Staff Moderator

2026-07-29T21:16:31.56+00:00

Thank you for the additional information @Augustine Wu

That's a good observation. If Azure Monitor is reporting that the container currently has 8 physical partitions, then based on that metric alone, physical partition count would not appear to explain the 39,000 RU/s minimum.

The highest RU/s ever provisioned ÷ 10 rule is a documented component of the minimum autoscale throughput calculation. However, without visibility into the service's internal metadata, we can't determine whether the current minimum is being enforced because of retained historical throughput metadata or another service-side factor.

In this scenario, I wouldn't recommend proceeding with Partition Merge solely based on the information available, as its primary purpose is to reduce the number of physical partitions, and your reported metric already indicates only 8.

To better understand why the service is enforcing a 39,000 RU/s minimum despite the reported partition count, we'd need the engineering team to verify the container's internal partition and throughput metadata.

Thank you for bringing up this discrepancy.

2 answers

Your answer

Augustine Wu 0 Reputation points Microsoft Employee

2026-07-27T15:19:54.9+00:00

Thank you @Pilladi Padma Sai Manisha for your suggestions. I have a follow up question. So on our container, and especially this one, I initially thought that maybe it was due to 39 physical partitions too, but by checking azure monitoring metric, we only have 8 physical partitions on this account, would it still help here to merge the partition?
Pilladi Padma Sai Manisha 11,705 Reputation points Microsoft External Staff Moderator

2026-07-29T21:16:31.56+00:00

Thank you for the additional information @Augustine Wu

That's a good observation. If Azure Monitor is reporting that the container currently has 8 physical partitions, then based on that metric alone, physical partition count would not appear to explain the 39,000 RU/s minimum.

The highest RU/s ever provisioned ÷ 10 rule is a documented component of the minimum autoscale throughput calculation. However, without visibility into the service's internal metadata, we can't determine whether the current minimum is being enforced because of retained historical throughput metadata or another service-side factor.

In this scenario, I wouldn't recommend proceeding with Partition Merge solely based on the information available, as its primary purpose is to reduce the number of physical partitions, and your reported metric already indicates only 8.

To better understand why the service is enforcing a 39,000 RU/s minimum despite the reported partition count, we'd need the engineering team to verify the container's internal partition and throughput metadata.

Thank you for bringing up this discrepancy.

Answer 1

Hi @Augustine Wu
The highest RU/s ever provisioned ÷ 10 term isn't really about throughput history; it's a proxy for physical partition count, and that's the piece that can't be silently rolled back.

When the container was pushed to ~390,000 RU/s, Cosmos split it across ~39 physical partitions (each partition serves up to 10,000 RU/s). Partition splits are one-way by default Cosmos won't auto-merge or relocate data on its own, because doing so transparently would risk latency, availability, and hot-partition regressions. So the high-water mark persists to represent "this container is laid out across N partitions," and the floor stays at 39,000 until that physical layout actually changes. That's why there's no time-based decay or in-place reset: storage/partition counts dropping doesn't collapse the underlying partition set by itself.

To actually lower the floor you have two supported paths:

Partition Merge (preview) reduces physical partition count so the minimum recomputes downward. Check preview eligibility for your account's API/throughput type, enable it, run the merge, then retry the scale-down.
Rebuild create a new container provisioned low from the start and migrate the data (Data Migration tool / Live Data Migrator / Spark). No peak history → low floor.

If neither is worth it, remember autoscale bills per-hour on the actual max between 0.1×Tmax and Tmax, so an idle container at a 39,000 max costs ~3,900 RU/s-equivalent, not the full 39,000.

Answer 2

Hi Augustine,

Your understanding is correct. For an autoscale container, the minimum maximum RU/s that you can lower to is based on:

MAX(1000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10)

rounded to the nearest 1000 RU/s.

So if the container was previously scaled to about 390,000 RU/s, the current floor of 39,000 RU/s is expected, even if the current storage is much lower.

I do not think the error message is giving the full reason. It mentions consumed storage, but based on the formula, the effective blocker in your case appears to be the historical maximum RU/s value.

As far as I know, there is no public self-service option to reset or decay that historical high-water mark on an existing container. If you need to get below that floor, the practical options are:

Open a Microsoft support case and ask if any backend remediation is possible for this specific container.
Migrate the data to a new container with the desired lower autoscale max RU/s.
Review whether partition merge helps your physical partition layout, but I would not assume it resets the historical RU/s floor unless Microsoft Support confirms that.

The “why no decay/reset” part is probably a product design question for the Cosmos DB engineering team. The current public documentation describes the formula but does not document a user-controlled reset mechanism for the historical peak.