Is the fraction on the allowed throughput per partition-delete or fixed limit?

[ImrePyhvel]

The overall deletion tests were a success and worked like a charm.

Currently, the 0.1 fraction is set by the Cosmos DB service. We are looking into ways to expose this control to the user and would welcome your feedback.

While the general 10% margin seems like a good default, it is not clear what happens when multiple partitions are deleted at the same time. Is the same 10% reserved for all deletions or is the actual impact on RU capacity Nx10%?

Having a better control of this "allowed throughput" seems necessary for some scenarios, I do hope it will not add any delays to general release of the base feature.

[deborahc]

Glad that it worked for your tests. The 10% is reserved for all deletions, we can clarify the documentation.

Can you tell us more about the scenarios where you'd like to have more custom control of the allowed throughput?

[ImrePyhvel]

For my current needs the 10% deletion reservation is perfectly ok and the imagined need is more on the hypothetical side.

• Many apps have rather fluctuating RU usage and plenty of unused RUs. Increasing the delete-reserved % would help get the index to sync faster (rather moot in case "Aggregate queries that use the index" known issue could be resolved).
• There could be the case where there is a stable high RU usage with fast-paced deletes (IoT perhaps) and trying to optimize cost by reducing the reserved amount to save a few % in cost.

It may well be that making this configurable is more hassle than it's worth, especially if the index sync delay gets sorted out.

Anyway, I won't complain if it remains at fixed 10%. It's still a highly anticipated feature.