Cosmos DB consistency: Strong, Bounded, Session or Eventual?
Verdict: RPO 0 means Strong - single write region only. A tenant-wide K-versions or T-seconds bound means Bounded staleness. Read-your-own-writes at the lowest RU cost means Session, the default. Multi-write accounts cannot run Strong.
| Criterion | strong consistency | bounded staleness | session consistency | eventual consistency |
|---|---|---|---|---|
| Guarantee | Linearisable - always the latest committed write | Lag bounded by K versions or T seconds, whichever first | Read-your-writes inside one session token | No ordering or freshness bound |
| RPO in region outage | 0 | K and T (minimums 100,000 ops / 300 seconds multi-region) | Under 15 minutes | Under 15 minutes |
| Read RU cost | 2x | 2x (two-replica reads) | 1x - same as Eventual | 1x |
| Cost elsewhere | Write latency grows with inter-region round trip | Near-strong for single-write multi-region | Cross-session reads can be stale | Highest throughput |
| Choose when | Trading, ledgers - staleness unacceptable | Global reporting, one write region, many read regions | User-facing web apps - the default for a reason | Counters, telemetry, likes |
Rules
- Choose Strong for RPO 0 with a single write region, accepting write latency proportional to inter-region round-trip time.
- Choose Session for read-your-own-writes at 1x read RU - Strong's 2x buys nothing when only the writer needs to see its writes.
- Choose Bounded staleness to cap cross-region lag at K versions or T seconds with one write region.
- Multi-write regions exclude Strong consistency entirely - and write conflicts become possible by design.
Traps
- Session's guarantee dies at the session-token boundary: other sessions can read stale data, so it cannot meet a tenant-wide freshness bound.
- Strong = RPO 0 and Session = RPO under 15 minutes in the outage table; tying Strong's RPO to K and T values confuses it with Bounded staleness.