Configure RU per region
For a database/collection that is made available in several regions, make it possible to provision RU capacity independently in each region. Use case: Secondary backup region that exists only as an up-to-date mirror of data in case the primary becomes unavailable, not to offload read operations under normal operation. Currently this means provisioning unused RU capacity, at a high cost, in the secondary region.
Hi Magnus. This is currently unplanned by us for our road map. Some context and feedback for you on this.
First, to do the replication itself to the secondary region you need RU/s sufficient to support the request rates for the primary region itself. Replication and writing to the secondary region itself is not free so there needs to be sufficient throughput provisioned to do that.
Second, for the secondary region to be able to function as the primary should a fail over occur, the replica region itself needs sufficient throughput to function as the primary.
Thanks again for your suggestion. Will mark as unplanned for now in case circumstances ever do change.
Nathan Oshlag commented
This feature would be extremely useful for scenarios like my team's where we have multiple data centers around the world for low-latency response times, but only one write region and it is a write-heavy database. This would enable us to be able to provision the necessary RUs for the write region and not need to overprovision the other data centers in the process.
Kaduk Frantisek commented
>>Second, for the secondary region to be able to function as the primary should a fail over occur, the replica region itself needs sufficient throughput to function as the primary.
I would keep it on the customer. If the customer decides to use this feature they take the risk of this issue. If so, there are 2 options: wheter manually upscale new region (we did it several times, no issues) OR having autoscale (we do he it now)
IMHO only the first reason is valid but could this be visible somewhere?
Camille Marvin commented
+1. I have two very high load regions and many smaller regions.
In case of failover I am OK with RUs for the smaller regions automatically being increased to match the region with the largest RU. However, for the usual case I don't need anywhere near that much RU in most regions.
Oddleif Halvorsen commented
Another use case is also that one is likely to have different loads across regions and/or time zones. For example, you have a much larger user base in one region, or it just peaks during business hours in the various time zones.
Ryan Ruby commented
RU costs are the same for each replica of a CosmosDB. In the absence of any failure in the Write region we could direct reads to different regions at a reduced cost.