Skip to main content

Global Database (beta)

In the global database, the replicas are distributed across multiple regions around the world. The clients are routed to the nearest region. This helps minimize latency for global use cases where users can be anywhere in the world.

Global Low Latency#

The Upstash Global database replicates your data across different AWS regions to optimize performance and minimize latency worldwide. Currently, the database is replicated to the following regions:

  • AWS US-East-1 North Virginia
  • AWS US-West-2 Oregon
  • AWS EU-Central-1 Frankfurt
  • AWS AP-SouthEast-1 Singapore
  • AWS SA-East-1 São Paulo

In our internal tests, we see the following latencies (90th percentile):

  • Read latency from main regions <10ms (US, EU, APAC)
  • Read latency from other regions <60ms
  • Write latency from anywhere <300ms


In the multi region architecture, each key is owned by a leader replica which is elected only among the replicas located in US and EU regions. Other replicas become the backups of the leader for the related keys. The leader replica processes the writes, then propagates them to the backup replicas. Read requests are processed by all replicas, this means you can read a value from any of them. This model gives a better write consistency and read scalability.

Each replica employs a failure detector to track liveness of the leader replica. When the leader replica fails for a reason, remaining replicas start a new leader election round and elect a new leader. This is the only unavailability window for the cluster where your requests can be blocked for a short period of time.


Global Database is designed to optimize the latency of READ operations. It is not a good choice if your use case is WRITE heavy.

Use Cases#

  • Edge functions: Edge computing (Cloudflare workers, Fastly Compute) is becoming a popular way of building globally fast applications. But there are limited data solutions accessible from edge functions. Upstash Global Database is accessible from Edge functions with the REST API. Low latency from all edge locations makes it a perfect solution for Edge functions

  • Multi region serverless architectures: You can run your AWS Lambda function in multiple regions to lower global latency. Vercel/Netlify functions can be run in different regions. Upstash Global database provides low latency data wherever your serverless functions are.

  • Web/mobile use cases where you need low latency globally. Thanks to the read only REST API, you can access Redis from your web/mobile application directly. In such a case, Global Database will help to lower the latency as you can expect the clients from anywhere.

High Availability and Disaster Recovery#

Although the main motivation behind the Global Database is to provide low latency; it also makes your database resilient to region wide failures. When a region is not available, your requests are routed to another region; so your database remains available.


Global Database does not support strong consistency yet. Currently it is an eventually consistent database. The write request returns after the leader replica processes the operation. Write operation is replicated to backup replicas asynchronously. Read requests can be served by any replica, which gives better horizontal scalability but also means a read request may return a stale value while a write operation for the same key is being propagated to backup replicas.

In case of cluster wide failures like network partitioning (split brain); periodically running anti entropy jobs resolve the conflicts using LWW algorithms and converge the replicas to the same state.

Upgrade from Regional to Global#

Currently, we do not support auto-upgrade from regional to global database. You can export data from your old database and import into the global database.


Global Database replicas your writes to 5 regions. Due to the increased cost, the price is higher for writes. It is $0.4 per 100.000 reads, $2 per 100.000 writes and $1.25 per GB-month. You can use Global Database in the free tier too. Free usage is limited with 2000 commands daily.

Global Database vs Edge Caching#

Both Global database and Edge caching help to minimize the global latency so both are good fits to edge computing use cases. The below are the differences to help you decide which one to use and when.

  • Edge caching caches the REST responses. Edge caching is possible only with the REST API. Global database supports both Redis clients and REST API. So use Global database if you are working with Redis clients.

  • Global database replicates your data to 5 regions. Edge caching caches your data to many more CDN locations. So if your clients are located heavily at edge locations which are not covered by 5 regions then Edge caching will give you better read latencies. You can enable Edge caching on a Global database to cover all locations.

  • With Global database, all reads will be fetched from the nearest region. With Edge caching, the first read will be get from the origin, the following reads will be fetched from the Edge cache.

  • Edge caching invalidates the cached data with a timeout (TTL) which is 30 seconds. So there is a window where your clients will read stale data until the cache is invalidated. Global database replicates the updates instantly to all replicas so data consistency is much better.

  • Both global database and edge caching are optimized for read heavy use cases. If your use case is write heavy (90% write) then it makes more sense to use a regional database instead of global database or edge caching.

  • You can use Global Database together with Edge Caching. If you want to minimize the read latency in all locations then enabling edge caching on a Global database is a good solution. Without the global database, edge caching will fetch the first requests from origin with higher latency.