This is covered in https://docs.microsoft.com/azure/cosmos-db/gremlin-support. You can specify a partition key for your graphs for scale out, and access vertices and edges using the partition key + item key ("id") like g.V(['USA', 'Seattle']).

The latency SLAs are within the same Azure region. You can distribute your data across any of the 30+ regions that Azure is available in. Your apps always read from the local/closest region with the homing APIs.

That didn't answer the question: will all regions be always consistent?

We would invite you to explore the consistency levels available in Cosmos DB. As a developer you can choose what makes most sense in distributed scenario. https://docs.microsoft.com/en-us/azure/documentdb/documentdb... Eventual is one end of the consistency. But then consistent prefix, session (if you can control) and bounded staleness all can play a role.

Tunable consistency. Very cool.

One key difference is the cost difference between running Cosmos DB and Cassandra. We have a TCO paper (https://aka.ms/documentdb-tco-paper) that shows that for a 1M operations/second workload, Cosmos DB is significantly 3x-10x cheaper than other systems.

In my experience of Cassandra (working on an application client, not managing it), one FTE per hundred nodes is extremely generous.

Do you mean that you typically need more engineers, or less?

The former. One FTE per dozen nodes is more in line with what I've seen in practice.

Cosmos DB guarantees both low latency and that you can achieve your provisioned throughput with SLAs. Latency is guaranteed at p99 regardless of storage size or number of partitions.

Sorry, I'm not talking about "number of partitions" but if I "forcibly"[0] hit the same partition, will the SLA hold?

[0] i.e. If I somehow pick keys which are on the same partition.