cosmos consistency
What it is
Consistency in Azure Cosmos DB is the promise about how fresh and ordered data appears when an application reads it. Cosmos DB replicates data; a change can reach different replicas at different times. The selected consistency level states what a read may see while that replication happens.
Think of a grocery price sign copied to several aisles. Strong consistency means every shopper sees the new price once the update completes. Weaker choices can let one aisle show the old price for a while, in exchange for faster or more available reads.
Why it exists
No distributed database gets the strongest freshness, lowest latency, highest throughput, and maximum availability for free. Cosmos DB offers five defined levels so an application can choose the trade-off that matches its data—not a universal “best” setting.
The five levels
| Level, strongest to weakest | Plain-language promise |
|---|---|
| Strong | A read returns the most recently committed version. |
| Bounded staleness | A read can lag, but only by configured time or version limits. |
| Session | Within one client session, a reader sees its own writes and does not go backward. |
| Consistent prefix | Readers never see writes out of order, but can lag behind. |
| Eventual | Replicas converge later; a read can be stale and can even appear older than an earlier read. |
Stronger consistency generally costs more read throughput or latency. Strong and bounded-staleness reads use more replicas than weaker levels; strong consistency also makes distant writes wait for replication.
Northwind example
When a shopper changes a grocery order, their own confirmation page must show that change. Northwind can use session consistency so that shopper’s session reads its own update. A public “most popular products” counter can tolerate eventual consistency: it may be briefly stale without harming an order. Northwind would choose strong only where its requirements truly need every read to see the latest committed data, and would measure the latency effect across its chosen regions.
How to choose safely
- Start with the business question: must this reader see its own write, a bounded delay, or the latest committed value?
- The account has a default consistency level; applications can override it for individual reads within supported limits. A change to the default should be tested with the application, not treated as a harmless switch.
- Consistency applies to a single read operation within a logical partition. It does not make an arbitrary multi-item business workflow atomic.
- Treat this choice separately from backups, recovery, and application authorization. It controls read observations, not who may access data.
Common confusion
- Eventual consistency does not mean data is lost. It means a read can temporarily see stale or differently ordered replicated data.
- Session consistency is not a promise that every unrelated user immediately sees a write. The guarantee depends on the client session and its session token.
- A consistency level is not the same as the change feed ordering rule.
Related
cosmos-db · cosmos-change-feed · azure-region · northwind-traders-case-study
Sources and re-audit
- Microsoft Learn — Consistency levels in Azure Cosmos DB, checked 2026-09-16.