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

TL;DR: Global databases are eventually consistent. A read right after a write can return the old value until replication reaches the read region. Read the same key from the primary region: it shows the new value. Read from the stale region again after a second: it converges.

The fix

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.
4. 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.
5. Design for it: version counters or timestamps on values so readers can detect staleness instead of trusting it.
6. 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.

When to use this

• This covers exactly what the title says: Stale reads on Upstash Global databases.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Stale; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

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