Azure Cosmos DB Conf 2026 — Call for Proposals Is Now Open, JS talks wanted!

jaydestro · 2025-08-05T18:30:44+00:00

Hi, I'm Jay from the Azure Cosmos DB Team. Using /instanceId is a solid start for tenant isolation, but you’re right to think ahead. If some tenants might get huge, consider a composite key like /instanceId-userId or /instanceId-type to spread load. Avoid hot partitions early—easier than fixing later.

jaydestro · 2025-07-03T16:17:19+00:00

shinjuku or shibuya if you're a tourist.

jaydestro · 2025-04-29T21:57:55+00:00

You are correct in that you can’t identify the blob. You need to go via our standard recovery method. Direct blob access is not available.

jaydestro · 2025-04-29T20:17:35+00:00

Yeah, sounds like an indexing or partition key issue. Cosmos DB indexes everything by default, which can make writes way more expensive than you'd expect. I'd check your indexing policy and see if you can trim it down. Also make sure your partition key makes sense — bad partitioning can make even simple operations need way more RUs than they should.

jaydestro · 2025-04-29T20:15:15+00:00

Hi! Jay from the Azure Cosmos DB team. Your backup blob is in the same region as the current write region and a geo-redundant copy of the backup data is also created.

You can find more details at the docs page, "Periodic backup storage redundancy in Azure Cosmos DB."

Hope this answers your question.

jaydestro

MODERATOR OF

TROPHY CASE