Cosmos DB Consistency & Partitioning
Five consistency levels · Partition keys · Hierarchical keys
Practice questions for this topic →
Consistency levels (strong → weak)
| Level | Guarantee | Typical use |
|---|---|---|
| Strong | Reads return the latest committed write (linearizable); highest write latency, lower availability during failures | Financial and inventory data |
| Bounded staleness | Lag bounded by K versions or T time; in order within the window | Need a defined maximum staleness |
| Session (default) | Read-your-own-writes within a session | Most user-facing apps, carts, profiles |
| Consistent prefix | Reads never see out-of-order writes | Ordered feeds where lag is acceptable |
| Eventual | No ordering guarantee; highest availability and performance, hardest to program | Counts and non-critical data |
- The account default applies to every database and container. A request can only relax consistency; to make reads stronger, change the account default (and redeploy the app). Overriding applies only to reads in that SDK client: an account set to Strong still writes and replicates synchronously to every region.
- Gremlin and Table accounts use the account's default level. Read consistency is scoped to a single read within a logical partition. Microsoft's page has a section on strong consistency with multiple write regions: check it before combining them.
Moving data to a new partition key: container copy order (Microsoft Learn)
- 1. Create the target container with the settings you want (partition key, throughput granularity, request units, unique keys). 2. Create the container copy job. 3. Monitor its progress. 4. After all documents are copied, stop updates on the source container and call the completion API. 5. Point the application or client at the source or target container.
- Online copy needs continuous backup and All versions and deletes change feed mode on the source account, plus the EnableOnlineContainerCopy capability (wait at least 30 minutes after enabling it). Replace and delete operations on the source incur an extra RU surcharge while online copy retains previous versions.
Partitioning
| Fact | Detail |
|---|---|
| Logical partition | All items with the same partition key value; up to 20 GB; unlimited number of logical partitions; scope of transactions (snapshot isolation); partition key + item ID uniquely identifies an item |
| Good key | High cardinality, evenly spread reads and writes, appears in query filters |
| Hierarchical keys | Up to 3 levels (for example TenantId / UserId / SessionId); prefixes can exceed 20 GB and 10,000 RU/s; every level needs high cardinality |
| Low first-level cardinality | Writes are confined to one physical partition until it reaches about 50 GB and splits |
| Change the key | Not in place: a container's partition key is fixed at creation. The portal's Change partition key feature (generally available, announced June 2, 2026; NoSQL API) copies the data to a new or existing container in the same database with container copy jobs, online or offline; in online mode you finish with Complete and then switch the app. Supported for containers under 1,000,000 RU/s and 4 TB; above that contact support; not supported for accounts with the merge partition capability |
Exam Tips
Tick each tip once you can answer it without looking.
“Reads must always return the most recent write” → Strong consistency.
“Users must see their own updates immediately; others may lag” → Session (default).
“Reads may lag but by no more than 5 minutes” → Bounded staleness.
“Highest throughput/lowest latency, staleness acceptable” → Eventual.
“Need strong consistency with multi-region writes” → Not supported: strong requires single write region.
“Large tenants exceed 20 GB per logical partition” → Hierarchical partition keys.
“All writes hit one partition (throttling 429s)” → Hot partition: choose a high-cardinality / synthetic key.
“Make one request stronger than the account default” → Not possible per request: raise the account default.
“Logical partition facts” → Same partition key value, up to 20 GB, unlimited count, scope of transactions. Trap: Partition key plus item ID uniquely identifies an item.
“Scope of Cosmos read consistency” → A single read within a logical partition. Trap: The account default applies to every database and container.
“Hierarchical key cardinality” → Every level needs high cardinality; low first-level cardinality confines writes to one physical partition until about 50 GB. Trap: Up to three levels.
“Change a Cosmos DB for NoSQL container's partition key” → Portal Change partition key feature (GA): copies data into a new or existing container in the same database, online or offline. Trap: The key can't be edited in place; in online mode finish with Complete, then switch the app.
“Change partition key limits” → Containers under 1,000,000 RU/s and under 4 TB; above that contact support. Trap: Not supported for accounts with the merge partition capability.
“Move a container to a new partition key with container copy” → Create the target container, create the copy job, monitor it, stop updates on the source and call the completion API, then point the app at the target. Trap: Online copy needs continuous backup and All versions and deletes change feed mode on the source; wait 30 minutes after enabling the capability.
“Cosmos DB consistency levels from strongest to weakest” → Strong, bounded staleness, session, consistent prefix, eventual. Trap: Strong increases write latency and lowers availability during failures; eventual is the fastest but hardest to program.