Vercel merges Data Cache into Runtime Cache with larger storage and new billing

One cache instead of two

Vercel announced on October 30, 2026 that Data Cache, its data caching service built for the Next.js App Router, is exiting beta and being consolidated into Runtime Cache. According to Vercel, the move leaves the platform with a single caching product that serves Next.js APIs, framework-agnostic code, and other frameworks alike.

The practical effect at the code level is minimal for most Next.js developers. Applications using Next.js fetch caching or unstable_cache switch over on every version of the framework without any code changes, Vercel says. Together with getCache and 'use cache: remote', all four caching APIs now share one set of storage budgets and usage tools.

Runtime Cache predates the consolidation by about a year. Vercel introduced it with a direct API, getCache from @vercel/functions, so developers could cache data without depending on Next.js. Cited use cases include feature flag lookups in Routing Middleware, caching CMS content during builds, and data caching in SvelteKit and Nuxt applications.

Storage grows, billing arrives

Storage expands alongside the consolidation. On Vercel's Pro plan, every project and environment now receives its own Runtime Cache allocation with eight times the space of Data Cache's previous team-wide pool. Enterprise projects get ten times their previous Data Cache storage. Vercel raised Pro storage budgets in June and Enterprise budgets in October, and says that among Enterprise projects with frequent evictions, cache miss rates roughly halved within a day.

The trade-off is billing. According to Vercel's changelog, Data Cache reads and writes that were previously unbilled will be charged at Runtime Cache pricing once a team migrates. Rates start at $0.40 per million read units and $4.00 per million write units, and vary by region. Hobby teams get one million read units and 200,000 write units free each month across all projects. On Pro, usage draws from the plan's $20 monthly infrastructure credit, with anything beyond billed at regional rates. Enterprise pricing is handled through account teams.

How the cache works

Runtime Cache is a distributed service shared by many teams: a Go API fronting Redis fleets in every Vercel region. According to Vercel, it handles more than 440 million reads and moves more than 18 TB of data every hour.

Each region keeps its own cache. A hit costs one round trip to the cache service in the region where the code runs, and on a miss the application or framework fetches or computes the value and writes it to that region's cache. The service does not check other regions for an existing copy. Authentication uses short-lived credentials managed by Vercel, so applications do not handle API keys.

Invalidation is tag-based. Every cached entry stores its tags and write time, and on read the service checks a regional tag store for those tags' invalidation timestamps. Invalidating a tag writes a single timestamp even if a million entries share the tag, and Vercel's global push pipeline, also used by the CDN, typically distributes the update to other regions within a few hundred milliseconds.

Reliability and observability work

Vercel also detailed recent engineering changes. In August it enabled circuit breakers in every region that let reads fall back on in-memory tag timestamps when a tag-store shard slows down, rather than blocking a cache hit. During the heaviest bursts in its largest region, p99 cache-service read latency fell to roughly one fifth of its previous level at comparable traffic, and on-call alerts for that failure mode stopped. The fallback has a caveat: a read can briefly treat recently invalidated data as fresh while it is active.

In Observability, Vercel added deployment markers, revalidation causes, and write utilization to the Runtime Cache view. These are meant to help teams correlate cache behavior with releases, see why entries get refreshed, and identify data that is written but rarely read.

Migration timeline

Teams created on or after October 30, 2026 use Runtime Cache by default. Existing Hobby teams will be migrated on November 29, 2026. Pro teams will be notified of their migration date and when billing changes take effect, and Enterprise teams will be contacted by their account team. Starting October 30, existing Hobby and Pro teams can opt in early from their CDN settings, though Runtime Cache pricing applies as soon as they do.

Vercel notes one partial escape hatch: disabling fetch and unstable_cache caching in CDN settings sends more requests to origin data sources but does not stop the migration.

Why it matters

The consolidation simplifies caching on Vercel into one product with one set of budgets and dashboards, and the per-project storage increase should reduce eviction pressure for larger applications. But the more consequential change is financial: cache traffic that Data Cache never billed for becomes metered usage after migration. Teams running Next.js on Vercel should review their Data Cache usage in Observability and follow Vercel's optimization guidance before their migration date, because previously free reads and writes will start drawing on credits or generating invoices. The move also signals where Vercel is heading: caching as a framework-agnostic platform capability rather than a Next.js feature.