- Vercel is folding Data Cache into Runtime Cache. It says teams using Next.js fetch caching or unstable_cache do not need to change their code.
- When the tag store is slow during traffic bursts, Vercel's circuit breakers let reads use in-memory tag timestamps, so a read can briefly treat recently invalidated data as fresh.
- Separately, Data Cache reads and writes that were unbilled will follow Runtime Cache pricing. Ask when your migration starts, what the bill looks like, and what a short stale read would affect.
Every cache trades freshness for speed. Vercel's October 30 post about merging two caching products describes that trade in unusually plain terms. The post announces two changes. They are separate, and this story keeps them apart.
What Vercel changed
Vercel is bringing Data Cache into Runtime Cache. Data Cache was the service behind Next.js fetch caching and unstable_cache. Runtime Cache already served the getCache function from @vercel/functions and the 'use cache: remote' feature in Next.js.
After the move, all four sit under one product. Vercel says teams that use fetch caching or unstable_cache do not have to edit their code.
How the cache works
Vercel explains that this cache differs from a CDN cache. A CDN stores complete web responses. Runtime Cache stores the data an application uses to build those responses. A product page can reuse cached catalog data while still personalizing the page for each visitor.
Each Vercel region has its own cache. On a miss, the app fetches the value and writes it to that region's cache. The service does not look in other regions for a copy.
Freshness works through tags. Each entry records its tags and when it was written. A separate tag store records when each tag was last invalidated. If a tag was invalidated after an entry was written, the entry counts as stale.
This keeps invalidation cheap. Vercel's example is a tag shared by a million cached entries. Invalidating it takes one timestamp write, not a million deletions. Vercel says the timestamp typically reaches other regions within a few hundred milliseconds.
A fallback for slow moments
That freshness check sits on every cache hit. Vercel describes a weak spot: in traffic bursts, a single sluggish shard of the tag store could make reads wait, although the cached value was sitting ready.
Vercel's answer was circuit breakers. When the tag store is slow, reads use tag timestamps held in memory instead of waiting. Vercel describes the cost this way: during the fallback, "a read can briefly treat recently invalidated data as fresh."
This is a fallback, not the normal path. The post does not say customers can switch it off or tune it.
Vercel reports that the breakers have run in every region since August. At the busiest moments in its largest region, it says the slowest one percent of reads, known as p99, fell to about a fifth of their earlier latency at similar traffic. Vercel adds that its engineers stopped receiving pager alerts for this problem.
These are Vercel's own measurements. The post does not say how often the fallback runs or how long the stale window lasts. It does not say whether any customer has been affected. Reading Vercel's account, reads no longer wait on a slow tag-store shard, which is where the speed under load appears to come from. Without frequency and duration, a buyer cannot judge how much that matters. That is the central open question.
Storage and billing, a separate change
The second change belongs to the migration. Vercel raised storage limits to reduce evictions, which happen when old entries are removed to make room. It raised Pro budgets in June and Enterprise budgets in October.
After migration, a Pro project gets a separate storage allocation for each environment. Vercel says that is eight times the space of the single pool Data Cache gave a whole team. Enterprise projects get ten times their earlier Data Cache storage.
Vercel reports that Enterprise projects that had been evicting often saw their cache miss rates drop by about half within a day.
On cost, Data Cache reads and writes that were unbilled will be charged at Runtime Cache rates. New teams start on Runtime Cache. Existing teams will get migration and billing details in advance. The post gives no prices and points to a changelog. The post does not connect this charge to the fallback.
Vercel also expanded the Runtime Cache view in Observability. It now shows deployment markers, the reasons entries were revalidated, and write utilization. These help teams see why entries refresh and which data is written but rarely read. Vercel advises reviewing cache usage before migrating, to cut unnecessary reads and writes.
What to ask your team
Five questions are worth putting to engineering this month.
First, when does our migration start, and what do we expect to pay under Runtime Cache pricing? Second, which cached data would cause a problem if shown stale for a moment, such as prices or stock levels? Third, if any cached data affects who can see what, is a short stale read acceptable there? The post does not say whether the fallback has affected such cases, so ask Vercel. Fourth, which data is written often and read rarely? The new write utilization view is meant to show this. Fifth, who owns the cache bill once it is no longer free?
A cache is a promise about how old an answer may be. Vercel has said publicly when that promise bends. Ask how often it bends.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Vercel.
