Confirmed changeVercel says fetch caching and unstable_cache will use Runtime Cache without code changes. The change is operational, not invisible: cache reads and writes become usage-based infrastructure costs.
Vercel Runtime Cache migration starts with new teams
Vercel’s October 30 changelog says Data Cache is exiting beta and moving into Runtime Cache. Teams created on or after October 30 use Runtime Cache by default. Existing Hobby and Pro teams can opt in early from the CDN settings.
Existing Hobby teams migrate on November 29, 2026. Pro teams will receive a date directly, while Enterprise teams should coordinate with their account team. There is no universal date for existing customers.
Cached `fetch` calls and `unstable_cache` switch without code changes. A product page using `fetch` with `force-cache` can keep running while its storage backend and billing model change.
| Plan or team | Published timing | Included allowance or action |
|---|---|---|
| New teams | Runtime Cache by default from Oct 30 | Monitor usage from the first deployment |
| Existing Hobby | Scheduled for Nov 29, 2026 | 1M reads and 200K writes monthly across projects |
| Existing Pro | Date sent directly by Vercel | $20 infrastructure credit applies before excess billing |
| Enterprise | Coordinate with account team | Contract and regional terms require confirmation |
Reads and writes become visible infrastructure costs
Vercel says pricing starts at $0.40 per million read units and $4 per million write units, with rates varying by region. Hobby receives one million reads and 200,000 writes per month across projects. Pro usage draws from the plan’s $20 monthly infrastructure credit before excess billing.
One cached pricing record may serve many requests from one write. A recommendation key that changes for every account can create far more writes. Traffic volume alone does not reveal which workload costs more.
Use Vercel’s regional pricing reference for the exact rate. Vercel says Pro receives eight times its previous team-wide allocation per project and environment, while Enterprise receives ten times. Larger capacity is not automatically efficient.
No code change does not mean no operating work
Record seven days of reads, writes, hit behavior, regions and origin requests, then repeat after the switch. Without a baseline, a higher bill or slower origin has no useful comparison.
A catalog record reused until an editor publishes is a strong cache candidate. A dashboard keyed by user, role, date and flags may create many low-reuse entries.
Vercel’s Runtime Cache optimization guide recommends looking for high-read keys and avoiding repeated cache reads in loops. Connect that evidence to a broader website performance optimization review so cost, cache hit behavior and user latency stay in the same decision.
- Reads and writes by project, environment and region
- The keys with the highest read and write volume
- Hit and miss behavior on critical public routes
- Database and external API traffic before migration
- Deployments, revalidation jobs and editorial publishes during the sample
Cache scope and deployment behavior still need review
Runtime Cache is regional and separated by environment. Vercel’s documentation says Pro and Enterprise storage is per project, while Hobby storage is shared by the team.
APIs also differ across deployments. Keys made with `use cache: remote` are not currently readable after a new deployment. Keys made through cached `fetch`, `unstable_cache` and the Runtime Cache SDK can be.
An editorial preview may repopulate safely. A public price list with a slow origin could suffer after a cold deployment. Put that route in the maintenance checklist.
Disabling caching can move the problem upstream
Vercel explicitly says disabling `fetch` or `unstable_cache` caching does not prevent the Runtime Cache migration. It shifts requests to databases, APIs or other origins instead.
A team might set every request to `no-store`. If a route then makes three database queries per visitor, compute, database and latency costs may exceed the avoided cache bill.
Treat cache policy as architecture, not a billing toggle. A Next.js partner should explain acceptable staleness, invalidation, fallbacks and origin limits.
Several outcomes remain unknown until teams migrate
The announcement does not publish every Pro date, predict a specific bill or guarantee faster responses. A project serving Paris and Washington can face different regional rates and cache patterns.
Vercel’s Runtime Cache overview explains the direction, but only observed usage resolves those unknowns. Record announcement facts, documentation and measured outcomes separately.
Run this cache audit before choosing the migration date
Use the published plan date as a deadline, not as the analysis. The following checks create enough evidence for an early opt-in or a deliberate wait.
- Confirm the plan, project, environments and regions in scope.
- Export a seven-day baseline of reads, writes and the highest-volume keys.
- Map each critical cached record to its freshness and invalidation rule.
- Test the current API across a deployment and a revalidation event.
- Estimate cost with the exact regional rate and the plan’s allowance or credit.
- Watch database, external API and user latency before and after migration.
- Record the owner, decision date and rollback or mitigation path.
Bring Seuil the cache evidence before the switch
Seuil can review one week of Vercel cache traffic, the critical route map and the current invalidation code. The useful output is a short migration decision with cost drivers, performance risks and named follow-up checks, not a blind opt-in because the button exists.