Vercel has folded Data Cache into Runtime Cache, so developers now have a single data-caching product spanning frameworks and APIs. Code that relies on Next.js fetch caching or unstable_cache continues to work unchanged, and Pro and Enterprise projects receive larger storage allocations.
From Next.js-only to a general caching service
Data Cache was introduced as Vercel's data caching layer for the Next.js App Router, backing both fetch caching and unstable_cache. It differs from CDN caching, which stores whole HTTP responses: Data Cache holds the data an application uses to build a response, letting a product page, for example, serve cached catalog data inside a personalized page. Runtime Cache was released last year to make that service available without a Next.js dependency, through a direct API — getCache from @vercel/functions — and is used for feature flag lookups in Routing Middleware, CMS content caching during builds, and data caching in SvelteKit and Nuxt apps. Frameworks can also expose it through their own APIs; Next.js uses the Runtime Cache API for 'use cache: remote', which caches function and component outputs.
Architecture and regional behavior
The service is a multi-tenant distributed cache: a Go API fronts Redis fleets in every Vercel region and handles more than 440 million reads plus over 18 TB of data movement every hour. Caches are regional, and a hit costs one round trip to the cache service in the region running your code. Authentication uses short-lived credentials, so there are no API keys to manage. On a miss, the app or framework fetches or computes the value and writes it into that region's cache; other regions are not consulted for a copy.
Tag-based invalidation
Every entry records its tags and its write time. A read checks a separate tag store in the same region for those tags' invalidation timestamps, and the entry is stale if any tag was invalidated after the entry was written. Tagging cached product data with catalog and invalidating that tag writes one timestamp rather than locating and deleting a million entries. The tag store in the requesting region is updated immediately; Vercel's shared tag infrastructure, also used by the CDN, pushes the timestamp through the global pipeline, usually reaching other regions within a few hundred milliseconds. Runtime Cache owns regional storage, authentication and cross-region invalidation distribution, while the app or framework decides what to cache and handles misses.
Improvements shipped this year
- Burst read latency. Freshness checks tied each hit to the tag store, so a slow shard could stall reads whose value was already available. Circuit breakers now let reads fall back to tag timestamps held in memory instead of waiting on the shard, at the cost of possibly treating recently invalidated data as fresh for a short window. They were enabled in all regions in August; in the largest region, p99 cache-service read latency during the heaviest bursts dropped to about one fifth of its prior level at comparable traffic, and on-call alerts for this failure mode stopped.
- Storage. Budgets rose for Pro projects in June and Enterprise projects in October, reducing evictions. Among Enterprise projects with frequent evictions, miss rates roughly halved within a day.
- Observability. The Runtime Cache view in Observability now shows deployment markers, revalidation causes and write utilization, so teams can correlate cache behavior with releases, see why entries refresh, and spot data written but rarely read.
What the consolidation changes
Previously the four APIs split across two backends: fetch caching and unstable_cache on Data Cache, getCache and 'use cache: remote' on Runtime Cache. All four now share one set of storage budgets and usage tools. No code changes are needed for fetch caching or unstable_cache users. On Pro, each project and environment gets its own allocation with 8x the space of Data Cache's former team-wide pool; Enterprise projects get 10x their previous Data Cache storage. Reads and writes that were previously unbilled follow Runtime Cache pricing. New teams start on Runtime Cache automatically, and existing teams will receive migration and billing details ahead of time. Rollout, pricing and early opt-in details are in the changelog; Vercel recommends reviewing cache usage and following the optimization guide to cut unnecessary reads and writes before migrating.
