Next.js Cache Upgrade: Data Cache Migrates to Runtime Cache

Vercel has announced that Data Cache is exiting beta and officially migrating to Runtime Cache. For developers using Next.js, this is a low-level upgrade that requires no code changes—fetch caching and unstable_cache will switch over automatically across all versions. But along with the architectural adjustment comes a fundamental change in how caching is billed.

Migration Core: Code Unchanged, Storage and Billing Restructured

According to the official announcement, after the migration, Next.js's fetch cache and unstable_cache will seamlessly switch to Runtime Cache, with developers not needing to modify any code. The real changes happen at the resource allocation and billing level.

Previously, Data Cache used a team-level shared storage pool. After migration, each project and environment under the Pro plan will receive an independent Runtime Cache storage quota—8 times the space of the original team shared pool. Enterprise projects get 10 times their previous Data Cache storage. This adjustment means cache resources shift from a "shared pool" model to a "per-project isolation" model. For multi-project teams, resource boundaries become clearer, but billing granularity also becomes finer.

The relationship between Runtime Cache and Data Cache: Runtime Cache is not an entirely new independent system—it is the official productized name Vercel gave to the previously beta-stage Data Cache. It carries Next.js's fetch cache and unstable_cache capabilities, still built on Vercel's edge network and regionalized storage. The difference is that Runtime Cache introduces a quota model isolated by project and environment, along with an independent dashboard, billing units, and optimization tools. For developers, the API and runtime behavior remain consistent—the changes are concentrated in resource governance and cost visibility, so the migration is imperceptible at the code level.

Billing Rules: Free Tier and Pay-as-You-Go

After migration, Data Cache reads and writes—previously free—will be charged according to Runtime Cache pricing. Rates start at $0.40 per million read units and $4.00 per million write units, varying by region.

Hobby teams receive 1 million read units and 200,000 write units free per month across all projects. Pro teams' usage is deducted from their $20 monthly infrastructure credit, with overages billed at regional rates. Enterprise customers should contact their account team for pricing.

This change has a significant impact on teams with high-frequency cache reads and writes. The official recommendation is to review your project's Data Cache usage via Observability before migration and refer to the optimization guide to reduce unnecessary reads and writes. Developers can also copy the official agent prompt into their coding agent to automatically apply optimization suggestions. In the Runtime Cache dashboard, users can also select "Optimize with Vercel Agent" for intelligent optimization.

What read units and write units mean: Vercel's cache billing uses "read units" and "write units" as the measurement units, rather than billing directly by request count or storage bytes. A single cache write typically corresponds to one fetch or unstable_cache result being persisted, while a read unit corresponds to a read operation when the cache is hit. The price difference between reads and writes (write units are about 10 times read units) reflects the higher cost of writes in storage and consistency maintenance. Regional rate differences stem from varying data center and network resource costs across regions. Teams can use Observability to break down usage by region and determine which deployment regions are driving costs.

Migration Timeline and Opt-In Choice

Migration proceeds in batches based on team creation date and plan type:

• New teams: Teams created on or after October 30, 2026 use Runtime Cache by default.
• Hobby teams: Teams already using Data Cache will be automatically migrated by the official team on November 29, 2026.
• Pro teams: The official team will notify you of the migration date and billing effective date.
• Enterprise teams: The account team will reach out to discuss migration details.

One detail to note: starting October 30, 2026, existing Hobby and Pro teams can opt in to Runtime Cache early from the team's CDN settings. Once opted in, Runtime Cache pricing takes effect immediately.

Additionally, users can disable fetch and unstable_cache caching in CDN settings. This sends more requests to the data source but does not block the migration process.

Practical Impact on Developers

From a technical perspective, this migration is an important evolution of Vercel's cache architecture. Runtime Cache provides larger storage space and finer-grained resource allocation, but the billing model shifts from "free" to "pay-as-you-go," requiring teams to manage caching strategies more proactively.

For projects with high cache read/write volumes, reviewing usage and optimizing before migration is essential. The official Observability tool and optimization guide are necessary starting points, while the introduction of the agent prompt and Vercel Agent lowers the barrier to optimization. For small and medium-sized projects, the free tier may be sufficient for daily use; but for high-traffic applications, cache costs will become an operational expense that needs to be budgeted for.

Overall, this migration is imperceptible at the technical level, but teams need to plan ahead at the cost and operations level. It is recommended that all teams using Data Cache complete a usage assessment before the migration window and decide whether to opt in early based on their own circumstances.

Trade-offs of disabling fetch and unstable_cache caching: After disabling caching in CDN settings, Next.js's caching layer will no longer intercept requests, and more traffic will reach the data source directly. This suits scenarios with low cache hit rates, extremely high real-time data requirements, or where cache costs exceed origin costs. However, disabling does not block the migration process or refund allocated Runtime Cache quotas—teams still need to complete the switch according to the migration timeline. For projects with fluctuating read/write volumes, a safer approach is to keep caching and reduce read/write frequency by adjusting revalidate periods and cache key design, rather than turning off the caching layer entirely.