Understanding Vercel Runtime Cache Pricing Before Moving From Data Cache

Do not estimate monthly costs from a single day of unusually high or low traffic. A better approach is to examine several weeks of usage and identify recurring patterns.

For example, a content website may generate a large number of cache writes whenever a publishing workflow updates articles. An ecommerce application may generate repeated writes because product information is revalidated too frequently.

The dashboard can help identify whether the application is read-heavy or write-heavy. That information is more useful than simply looking at the total number of cached entries.

Also review the usage of individual projects. A team-wide total can hide one application that produces most of the cache activity.

Why Some Applications Generate Too Many Cache Writes

High cache usage does not always mean an application has heavy traffic. Sometimes the caching strategy itself creates unnecessary operations.

Consider a product catalogue with thousands of items. If the application caches each product independently and uses a short revalidation period, frequently accessed products may be refreshed more often than necessary.

Another example is a website with a large number of long-tail URLs. Many pages may be requested only once or twice. Caching their data can generate writes without producing enough future reads to justify the storage operation.

These patterns are worth investigating before migration.

Short revalidation periods

A short revalidation interval can cause frequently requested data to be refreshed repeatedly.

For example, an application that refreshes product information every few seconds may create unnecessary writes if the underlying data changes only once every several minutes.

Choose a revalidation period based on how frequently the source data actually changes.

High-cardinality cache entries

High-cardinality caching occurs when an application creates many different cache entries for slightly different inputs.

Search pages are a common example. If every search phrase creates a separate cached result, many entries may receive only one request.

Caching every possible search result is not always beneficial. For low-frequency queries, fetching directly from the source may be more economical.

Repeated writes for unchanged data

An application may refresh a cached value even when the source data has not changed.

If the application can detect meaningful changes before writing new values, it may reduce unnecessary writes.

The correct implementation depends on the framework's caching API and the application's consistency requirements. Avoid adding complicated comparison logic where the cost of checking for changes is higher than the cache operation itself.

Review the Existing Next.js Caching Code

The migration does not require changing existing fetch caching or unstable_cache calls. Vercel handles the transition to Runtime Cache without requiring application code changes.

For example, an application may currently use:

async function getProducts() {
  const response = await fetch(
    "https://api.example.com/products",
    {
      next: {
        revalidate: 300
      }
    }
  );

  if (!response.ok) {
    throw new Error("Unable to retrieve products");
  }

  return response.json();
}

This example caches the fetched response according to the configured revalidation period.

A project using unstable_cache might have code like this:

import { unstable_cache } from "next/cache";

export const getProductDetails = unstable_cache(
  async (productId: string) => {
    return database.product.findUnique({
      where: {
        id: productId
      }
    });
  },
  ["product-details"],
  {
    revalidate: 300
  }
);

These existing APIs continue to work through the migration. Developers should not rewrite working caching code simply to make it use Runtime Cache.

However, the migration is a good opportunity to review whether every cached operation is still necessary.

Also remember that unstable_cache is an existing API. Teams adopting newer Next.js caching features should follow the documentation for their installed framework version rather than treating every caching API as interchangeable.

Should You Disable Data Cache to Avoid the New Charges?

Vercel provides an option to disable fetch and unstable_cache caching through CDN settings.

At first glance, disabling caching may appear to be a simple way to avoid Runtime Cache charges. However, it changes how the application retrieves data.

Without the cache, requests that previously reused stored data may reach the original API or database more frequently.

That can introduce other costs:

• Increased database queries.
• More external API requests.
• Longer response times.
• Higher function execution usage.
• Additional load on backend services.

It also does not prevent the team's migration to Runtime Cache.

For an application that relies heavily on cached data, disabling caching without measuring the impact can make the overall infrastructure more expensive.

A better decision is to identify unnecessary cache activity and optimize it. Disable caching only for data that does not benefit from reuse, such as highly unique search queries or values that must always be fetched fresh.

What Developers Should Check Before Migration

A practical review should cover both application behavior and billing.

Start with the following checks:

1. Open the Vercel dashboard and review Data Cache usage in Observability.
2. Compare read and write volumes across projects.
3. Identify functions that generate frequent cache writes.
4. Review short revalidation intervals and high-cardinality cache entries.
5. Check whether cached data is reused often enough to justify the writes.
6. Estimate costs using the region-specific Runtime Cache rates.
7. Review the migration date communicated by Vercel.
8. Monitor Runtime Cache usage after the migration.

Vercel also provides an optimization guide and an option to use Vercel Agent from the Runtime Cache dashboard. These can help identify inefficient caching patterns.

Do not make several caching changes at once without measuring their effects. Changing revalidation periods, removing cache entries, and disabling caching together makes it difficult to determine which change improved or worsened usage.

When Does the Migration Happen?

Vercel announced the migration on October 30, 2026.

Teams created on or after that date use Runtime Cache by default.

For existing teams, the migration schedule depends on the plan:

• Hobby teams are scheduled to migrate on November 29, 2026.
• Pro teams will receive notification of their migration date and when billing changes take effect.
• Enterprise teams will receive migration details through their account team.

Existing Hobby and Pro teams can also opt in early through their team's CDN settings. However, Runtime Cache pricing applies as soon as they opt in.

This is worth remembering when testing the new service. Opting in early is not simply a technical preview with the old billing behavior.

Conclusion

Vercel's move from Data Cache to Runtime Cache does not require existing Next.js applications to rewrite their caching code. The important change is how cache operations are measured and billed.

Read and write operations that were previously unbilled will become chargeable after migration. Because writes are more expensive than reads, applications with frequent revalidation or large numbers of short-lived cache entries should review their usage before the change takes effect.

Start by examining the actual usage in Vercel Observability, identifying unnecessary writes, and estimating costs using the correct regional rates. Avoid disabling caching without considering the additional load on databases and external APIs.

Caching should improve application performance, but it should also have a clear purpose. The migration is a good opportunity to check whether the application is storing data that users actually reuse or simply generating cache activity without meaningful benefit.