Skip to main content

Edge Caching (deprecated)


Edge caching has been deprecated. Please use Global Database which has a similar latency.

Edge Caching caches your REST API responses on globally distributed edge locations (CDN). Edge caching decreases the global latency up to 70%.

By default, edge caching is disabled for a new database. You can enable it in database details page in the Upstash Console. Enable edge caching when:

  • Your Redis clients are globally distributed to multiple regions.
  • You need low latency globally.
  • You access your Redis from edge functions (Cloudflare, Fastly).

Edge caching is only available for the REST API. It is not supported in free tier.

Get Started

In your database detail page click on the ⚙️ icon next to Edge Caching Enabled field. Once enabled, click on the REST APIbutton to see the Edge URL. Use the Edge URL in your REST calls.

Cache Expiration

The cached responses expire in 30 seconds by default. You can override this by setting Cache-Control: max-age=<seconds> in your header. You can set max 900 (15 minutes) as max-age. You can also Cache-Control: no-cache if you want to skip caching the response for a request.


curl \
-H "Authorization: Bearer 2553feg6a2ddsfdsc842h2a08efe9934"
-H "Cache-Control: max-age=50"

The first request to the above URL will fetch the response from the Upstash Redis. The next requests will be fetched from edge locations. The cached responses will expire in 50 seconds at each edge location.


Only GET requests are supported in Edge Caching. As a result, write/update commands and some read commands (e.g. PIPELINE) are not supported as they work with POST request. You can use the standard REST URL for them.


Edge caching has an additional cost. For more info please see Edge Caching Pricing section.

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.