Verified against Microsoft Learn on September 29, 2026. Every guarantee, quorum, latency figure, and override rule on this sheet comes from the two pages below.
The five levels#
Azure Cosmos DB offers five levels, from strongest to weakest. The default level on the account applies to every database and container in it, and Session is the default for new accounts. Azure Cosmos DB guarantees that 100% of read requests meet the level you choose.
Strong
2× read RU
Linearizable. Every read returns the most recent committed write, in every region. Writes commit in every region before they are acknowledged.
Bounded staleness
2× read RU
Reads in another region lag writes by at most K versions or T time, whichever is reached first. Within a region, reads return the newest data.
Session
Default · 1× read RU
Read your own writes and write follows reads within one client session, or across clients that share the session token.
Consistent prefix
1× read RU
Single-item writes behave as eventual. Items written together in a transaction are always seen together, in commit order.
Eventual
1× read RU
Any one of the four replicas answers, so a read can return older data. Ideal when order is irrelevant, such as like counts.
Guarantees at a glance#
Every region keeps four replicas of each partition. The consistency level decides how many replicas a read consults and where a write must commit.
| Level | Read quorum | Read cost | Write quorum | RPO: more than one region, single write region |
|---|---|---|---|---|
| Strong | Local minority (two replicas) | 2× | Global majority (every region) | 0 |
| Bounded staleness | Local minority (two replicas) | 2× | Local majority (three of four) | K and T |
| Session | Single replica, using the session token | 1× | Local majority (three of four) | Under 15 minutes |
| Consistent prefix | Single replica | 1× | Local majority (three of four) | Under 15 minutes |
| Eventual | Single replica | 1× | Local majority (three of four) | Under 15 minutes |
Write RU is identical at every level. Only reads change: strong and bounded staleness read two replicas, so each read costs twice the RU of the three weaker levels.
- Single region account: the RPO is under 240 minutes at any level.
- Multiple write regions: session, consistent prefix, and eventual keep an RPO under 15 minutes; bounded staleness keeps K and T.
- Strong consistency requires a single write region. A distributed system cannot deliver an RPO and an RTO of zero at the same time, and every write still commits in every region.
Latency#
| Operation | 99th percentile | 50th percentile (typical) |
|---|---|---|
| Reads, every level | Under 10 ms | 4 ms or less |
| Writes, every level | Under 10 ms | 5 ms or less |
| Writes, strong with more than one region | 2 × round-trip time between the two farthest regions, plus 10 ms |
- Strong consistency across regions more than 5,000 miles (8,000 kilometers) apart is blocked by default because of write latency. A support request enables it.
- Dynamic quorum: a strong account with three or more regions can drop slow regions from the write quorum. Three or four regions can drop one region; five regions can drop two. A dropped region serves reads again once it rejoins the quorum.
Bounded staleness settings#
| Account | Minimum K (versions) | Minimum T (time) |
|---|---|---|
| Single region | 10 write operations | 5 seconds |
| More than one region | 100,000 write operations | 300 seconds |
- Lag is measured per physical partition. When a partition exceeds the bound, writes to that partition are throttled until the lag is back within the limit.
- The minimum K and T define the minimum RPO for bounded staleness.
- Bounded staleness fits single write region accounts with two or more regions that want near strong reads. With multiple write regions it is an anti-pattern: keep reads and writes in the local region instead.
Session tokens#
- The client receives a new session token after every write and sends it with reads.
- Tokens are partition-bound: use the most recent token for the items you read.
- A client that has not written to a physical partition holds no token for it, so its reads there behave as eventual. A recreated client starts with an empty token cache.
- An older token still returns the latest data. The token is a minimum version barrier, not a request for a historical version.
- Pass tokens between client instances unchanged.
Overriding the account default#
Overrides apply to reads only. Writes always follow the account default, so a strong account still writes synchronously to every region.
| Capability | ConsistencyLevel override | ReadConsistencyStrategy |
|---|---|---|
| Relax below the account default | Yes | Yes |
| Strengthen above the account default | No | Yes |
| Set on the client or per request | Yes | Yes |
| Values | Strong, Bounded staleness, Session, Consistent prefix, Eventual | Default, Session, Eventual, Latest Committed, Global Strong |
| SDK support | All SDKs | .NET SDK v3.46 and later, Java SDK v4.69 and later |
- When a request sets both, ReadConsistencyStrategy takes precedence.
- To strengthen consistency with the classic override, raise the account default instead.
- Restart the application after changing the account default, so every SDK client is recreated with the new level.
Match the requirement to the level#
When a question asks for the lowest cost or highest throughput option, choose the weakest level that still meets the requirement.
| Requirement in the question | Weakest level that meets it |
|---|---|
| Reads must always return the latest committed write, in every region | Strong |
| Reads in other regions can lag by at most a set number of versions or seconds | Bounded staleness |
| Users must always see their own changes | Session |
| Items written together in a transaction must appear together and in order | Consistent prefix |
| Lowest cost and highest availability; order is irrelevant | Eventual |
