What happened
On October 30, 2026, Vercel said it is consolidating Data Cache into Runtime Cache. Data Cache began as Vercel's data caching service for the Next.js App Router and powered fetch caching and unstable_cache. Runtime Cache is the broader service Vercel introduced last year, with a direct getCache API from @vercel/functions. The consolidation means those two Next.js APIs join getCache and Next.js's use cache: remote on one underlying product.
The distinction matters because this is data caching rather than CDN response caching. A CDN can store a full HTTP response. Vercel describes Data Cache and Runtime Cache as storing the data used to construct that response, allowing an application to reuse catalog data while still rendering a personalized product page. The direct Runtime Cache API can be used for feature-flag lookups in Routing Middleware, CMS content during builds, and application data caching in SvelteKit and Nuxt. Frameworks can also expose the service through their own APIs.
No code change is required for projects already using Next.js fetch caching or unstable_cache. New teams use Runtime Cache automatically. Existing teams will receive migration and billing details in advance, with a changelog carrying rollout, pricing, and early opt-in information. The important commercial change is that Data Cache reads and writes that had previously been unbilled will follow Runtime Cache pricing after migration.
Vercel is also changing capacity. Pro projects receive a storage allocation for each project and environment, with eight times the space of the former team-wide Data Cache pool. Enterprise projects receive ten times their former Data Cache storage. Vercel says it raised Runtime Cache budgets for Pro in June and Enterprise in October; among Enterprise projects with frequent evictions, cache miss rates roughly halved within a day. The company advises customers to review usage and reduce unnecessary reads and writes before migrating.
The shared service is regional. A Go API handles requests over Redis fleets in every Vercel region; Vercel says it processes more than 440 million reads and more than 18 TB of data each hour. A cache hit makes one round trip to the cache service where code is running. On a miss, the application or framework computes or fetches a value and writes it in that region; the service does not look for a copy in another region.
Entries record tags and write time. On reads, Runtime Cache compares those tags with invalidation timestamps in a regional tag store. Invalidating a tag writes one timestamp rather than deleting every associated entry, and Vercel's global push pipeline typically distributes that timestamp to other regions within a few hundred milliseconds. Circuit breakers introduced in all regions in August can temporarily use in-memory tag timestamps when a slow tag-store shard would otherwise hold up a read. Vercel says this can briefly treat recently invalidated data as fresh, while p99 cache-service read latency during the largest bursts in its largest region fell to about one fifth of the earlier level at comparable traffic.
What the archive adds
This is a new operational and pricing fact on a known Vercel caching story, rather than a restatement. In Vercel Agent sessions now cost 67% less on average after context and caching rework, Vercel reported lower average agent-session cost after changes to context, caching, and workflow skills, without changing billing rates. This update identifies a separate platform-level consolidation: cache APIs, capacity allocation, and the future charging surface are being brought together.
Trend signal
No supplied pattern is a sufficiently direct fit: this is primarily a managed-platform consolidation and billing transition, not evidence for one of the recorded structural claims.
Why now
Vercel presents the move as the endpoint of a broader expansion beyond the Next.js App Router. It introduced Runtime Cache's direct API last year, then added performance, storage, and observability work over the past year. The company says circuit breakers were enabled in August, Pro storage rose in June, and Enterprise storage rose in October. Consolidation now makes those improvements and one set of storage budgets available across the four APIs.
Why it matters
For teams building AI-enabled applications, cached data often sits on a request path: feature flags, permissions-adjacent configuration, retrieved CMS content, computed intermediate values, and response inputs. One cache surface reduces the need to reason separately about framework-specific behavior and function-level caching. It may also make Observability more useful because deployment markers, revalidation causes, and write utilization are reported in the Runtime Cache view.
The trade-off is financial and architectural visibility. Compatibility prevents an immediate code migration, but it does not preserve the old economic model: formerly unbilled Data Cache reads and writes will be priced as Runtime Cache usage. Regional behavior also remains material. A value missed in one region is recomputed or fetched there rather than retrieved from another region. Teams should therefore treat the migration as an opportunity to measure key cardinality, write frequency, invalidation behavior, and actual read reuse rather than as a purely administrative rename.
What happens next
- Existing Vercel teams will receive migration and billing details before their cache transition. (3 months, 85%). Watch for: a project-level migration notice or the referenced rollout changelog.
- More teams will use the unified Runtime Cache observability view to identify low-value writes before paid usage begins. (6 months, 65%). Watch for: declining write utilization on workloads formerly using Data Cache.
Limits and uncertainty
The announcement does not state the Runtime Cache price, the exact migration timetable for every existing team, or how much a particular workload will cost after formerly unbilled operations move to the new pricing model. Vercel's latency and eviction figures are company-reported operational measurements, not an independent benchmark, and the source does not give absolute latency values or the size of the affected Enterprise cohort. It also does not establish that every application benefits equally from the larger allocations: outcomes depend on access patterns, regional traffic distribution, entry size, expiry, and invalidation design.
Skill to build now
Create a cache inventory for one production service this week. List each cached key family, its region-sensitive inputs, tags, write trigger, invalidation path, approximate read-to-write ratio, and what happens on a miss. Then use Vercel's cache observability data to find entries that are written frequently but rarely read. That gives a concrete baseline for evaluating the migration's storage increase and any new Runtime Cache charges, while reducing waste independently of the platform change.
Reader takeaway
Vercel's cache consolidation is code-compatible for common Next.js users, but it is not economically invisible. One Runtime Cache will now cover the major framework and functions APIs, with larger allocations and better shared visibility; teams should use the advance notice period to understand which cached work is genuinely reused and which operations will become paid traffic.
Open question
Will the forthcoming migration details provide per-project forecasts that let existing Data Cache users estimate their Runtime Cache bill before the billing transition takes effect?