Vercel Unifies Runtime Cache: Data Cache Merges into Runtime Cache

Vercel is consolidating its scattered caching products into a single system. Data Cache has been merged into Runtime Cache, so developers no longer need to choose between two caching systems. For projects using Next.js fetch caching or unstable_cache, no code changes are required, but billing and storage quotas will change.

Why Runtime Cache Is Needed

Data Cache was originally a data caching service designed for the Next.js App Router, powering fetch caching and unstable_cache. Its division of labor with CDN caching was clear: CDN caching stores complete HTTP responses, while Data Cache caches the data an application uses when generating a response. A product page can reuse cached product catalog data while still rendering personalized content for each visitor.

The problem was that this capability remained tied to Next.js for a long time. Vercel then introduced Runtime Cache, offering a direct API via getCache in @vercel/functions, allowing frameworks such as SvelteKit and Nuxt to use it as well. This covers scenarios like feature flag lookups in route middleware and build-time CMS content caching. Frameworks can also wrap this layer themselves—Next.js's 'use cache: remote' caches function and component output through the Runtime Cache API.

The division of labor between Data Cache and CDN caching needs to be understood in terms of the caching object hierarchy. CDN caching (on Vercel, the Edge Network cache) stores complete HTTP responses, typically keyed by URL plus request headers. On a hit, the entire response is returned directly, and the application server is not involved at all. Data Cache stores intermediate data produced during application rendering—for example, database query results, JSON returned by CMS APIs, computed results, and so on. It has no direct control over the final HTML. The two can stack: a request may first hit the CDN and get a finished page, or it may miss the CDN, enter the function, hit Data Cache to reuse data, and only re-render the personalized portion. Because they operate at different layers, the merged Runtime Cache does not replace CDN caching—the former solves "data reuse," while the latter solves "response reuse."

How Runtime Cache Works

Runtime Cache is built on a distributed caching service shared by many teams: a Go API handles requests, and behind each Vercel region is a Redis cluster. According to Vercel, the service handles more than 440 million reads per hour and moves more than 18 TB of data.

Caching is isolated by region. A hit requires only a single round trip, and authentication is handled by Vercel using short-lived credentials, so developers do not need to manage API keys. On a miss, the application or framework fetches or computes the value itself and then writes it to the local region's cache; the service does not look for copies in other regions.

The invalidation mechanism deserves separate mention. Each cache entry records tags and a write time. On reads, the service checks these tags' invalidation timestamps against a separate tag store in the same region. If a tag was invalidated after the entry was written, the entry is considered stale. This means invalidating a catalog tag only requires writing a single timestamp—even if millions of entries share that tag, there is no need to delete them one by one. The tag infrastructure is shared with the CDN, and invalidation timestamps are distributed through a global push pipeline, typically reaching other regions within a few hundred milliseconds.

Tag-based invalidation is a caching invalidation paradigm that contrasts with "delete by key." The traditional approach is to enumerate or record all relevant keys during invalidation and then delete them one by one, which is costly and error-prone at large entry counts. Tag-based invalidation attaches one or more tag names to each entry and maintains a separate "tag → most recent invalidation timestamp" mapping. On reads, it compares the entry's write time with the tag's invalidation timestamp; if the write is earlier, the entry is deemed stale. This reduces invalidation from O(number of entries) to O(number of tags)—only one timestamp needs to be updated. The cost is an extra timestamp check on every read, which is the source of the article's statement that "determining whether an entry is fresh adds a dependency call to every hit"; the circuit breaker exists precisely to skip this check when the tag store slows down.

Three Recent Improvements

Faster Reads Under Traffic Peaks

Determining whether an entry is fresh adds a dependency call to every hit. During traffic peaks, a slow shard in the tag store can slow down reads even when the cached value is already available. Vercel added a circuit breaker that lets reads temporarily use in-memory tag timestamps to judge freshness, bypassing slow shards. The trade-off is that during fallback, recently invalidated data may briefly be treated as fresh. This mechanism is enabled in all regions, and according to Vercel's data, p99 read latency in the largest region at peak dropped to about one-fifth of its previous level, and the related alerts no longer fire.

p99 latency refers to the response time at the 99th percentile after sorting all requests by duration—that is, the threshold for the slowest 1% of requests. Compared with average latency, p99 better reflects the "long-tail stalls" in user experience: the average is pulled down by a large number of fast requests, while a small number of slow requests often determine whether users perceive a stall. When the article says "p99 read latency dropped to about one-fifth of its previous level," it means tail-end slow requests during high-traffic periods were significantly reduced. The accompanying circuit breaker mechanism comes from distributed systems practice: when a dependency consistently slows down or fails, calls to it are temporarily cut off and a local fallback is used instead, preventing request queuing from dragging down the entire chain, and traffic is allowed through again once the dependency recovers. Falling back to in-memory tag timestamps, as described in the article, is a typical degradation path, with the cost of a brief consistency window.

More Storage, Fewer Evictions

Pro projects had their storage budgets increased in June, and Enterprise projects in October. More space means fewer cache entries are evicted to make room. In Enterprise projects with frequent evictions, the cache miss rate was roughly halved within about a day.

More Observable Cache Behavior

The Runtime Cache view in Observability now includes deployment markers, revalidation reasons, and write utilization, helping developers correlate changes in cache behavior with releases, see why entries were refreshed, and identify data that is written but rarely read.

What Changes After the Merge

Previously, Next.js fetch caching and unstable_cache went through Data Cache, while getCache and 'use cache: remote' went through Runtime Cache. After the merge, all four APIs are served by Runtime Cache, with storage quotas and tooling consolidated into a single system—friendlier for teams using coding agents.

At the code level, nothing changes; at the billing level, things do. Pro projects get an independent storage quota per project and environment, 8 times the space of Data Cache's original team-shared pool; Enterprise projects get 10 times their previous Data Cache storage. Data Cache reads and writes that were previously free will now be billed at Runtime Cache pricing. New teams automatically use Runtime Cache, and existing teams will receive migration and billing details in advance. Vercel recommends checking cache usage before migrating and following optimization guidance to reduce unnecessary reads and writes.

The signal from this merge is clear: caching is evolving from a framework add-on into platform-level infrastructure. For teams with multiple frameworks, unified quotas and observability reduce cognitive overhead; for cost-sensitive teams, the billing rule changes require doing the math in advance.

One-line Summary

Vercel merges Data Cache into Runtime Cache, unifying regional caching and changing billing and quotas.

Paragraph Summary

Vercel has merged the Data Cache that originally served Next.js into the platform-level Runtime Cache, so the four APIs—fetch caching, unstable_cache, getCache, and use cache: remote—are all served by the same distributed cache. Runtime Cache is isolated by region and consists of a Go API plus Redis clusters in each region, handling more than 440 million reads per hour and moving over 18 TB of data. Invalidation uses a tag timestamp mechanism that avoids deleting entries one by one, and distributes changes across regions within a few hundred milliseconds via a global push pipeline. Recent improvements include a circuit breaker that lowers peak p99 latency, larger storage budgets that reduce evictions, and new cache observability metrics in Observability. After the merge, no code changes are needed, but Pro and Enterprise storage quotas expand to 8 times and 10 times the original Data Cache, respectively, and previously free reads and writes will be billed at Runtime Cache pricing.