Stale reads on Upstash Global databases: eventual consistency is by design

Diagnosing stale reads on Upstash Global databases

Symptom

A write succeeds, but a read from another region returns the old value for a few hundred milliseconds. Tests that write-then-read across regions flake.

Cause

Global databases are eventually consistent by design. The write returns after the primary region processes it, then replicates to read regions asynchronously. A read landing on a region that has not received the write yet returns stale data. This is documented behavior, not replication lag to fix.

Confirm

1. Read the same key from the primary region: it shows the new value.
2. Read from the stale region again after a second: it converges.
3. Check you are actually on a Global database. Regional databases

do not have this behavior.

Fix options

• Read-your-writes: after a write, read from the primary region for that request, or keep a short client-side cache of just-written values.

• Design for it: version counters or timestamps on values so readers can detect staleness instead of trusting it.

• If your workload is write-heavy or needs strong consistency, a Global database is the wrong choice. Use a regional database in the region where the writes happen.

The docs say it directly: Global optimizes read latency, not write consistency.

Verify

Re-run the cross-region write/read test. Staleness windows shrink to the documented propagation time, and your read-your-writes path never shows stale data.

Verified against Upstash global database docs: writes process at the primary region then replicate asynchronously to read regions; reads can be served by any replica and may return stale values during propagation; conflicts resolved with LWW anti-entropy. Source: https://upstash.com/docs/redis/features/globaldatabase