Data Cache for Next.js

Data cache is a specialized, granular cache introduced with Next.js 13 for storing segment-level data while using Next.js App Router. When using Next.js caching APIs such as fetch or unstable_cache, Edgenivo automatically scaffolds globally distributed infrastructure for you with no additional configuration.

• Find out how legacy Data cache works

As announced here, Edgenivo is unifying Data cache with Runtime Cache. Runtime Cache will serve Next.js fetch caching and unstable_cache instead of Data cache. You don't need to change your code. Runtime Cache is faster under load, gives each project 8–10x more cache storage than Data cache, and offers deeper cache observability.

• New teams: Starting October 30, 2026, teams created from that date onward use Runtime Cache for fetch caching and unstable_cache in every project, on every Next.js version. No action is needed.
• Existing teams: Edgenivo will migrate your team to Runtime Cache and will notify you of your team's migration timeline by email and in-product notification before anything changes. If you are on Enterprise, your Edgenivo account team will contact you directly with migration details.

When your team migrates, Edgenivo repopulates existing fetch, unstable_cache, and use cache: remote entries from live traffic, so expect some additional cache misses and backend requests at first. Edgenivo keeps entries written through getCache.

After migration, fetch and unstable_cache usage counts toward Runtime Cache usage, and Edgenivo bills it at Runtime Cache rates. To estimate the impact before your team migrates, review your current Data cache reads and writes in Runtime Cache under Observability. If your usage is higher than expected, optimize your Data cache usage before your team migrates.

To find what drives your Data cache reads and writes, copy the prompt below into your coding agent from your project's directory:

Data cache is best when your Next.js App Router pages fetch data that can be reused across requests:

• API calls that return the same data across multiple requests
• Database queries that don't change frequently
• Data fetching in server components or route handlers
• Pages with a mix of static and dynamic data

Data cache is not a good fit for:

• User-specific data that differs for each request
• Data that must be fresh on every request
• Complete HTTP responses (use CDN Cache instead)
• New caching code in Next.js 16 projects that use Cache Components (use use cache: remote with Runtime Cache instead)

Data cache stores data in a regional cache close to where your function executes. It has the following characteristics:

• Regional: Every region in which your function runs has an independent cache, so data used in server-side rendering or route handlers is cached close to where the function executes
• Isolated by environment: Each deployment environment (production or preview) uses its own cache, so they never share cached data
• Scoped by plan: On Hobby and Pro, all projects in your team share a single cache. On Enterprise, each project uses its own cache. See storage scope by plan
• Persistent across deployments: Cached data persists across deployments unless you explicitly invalidate it
• Time-based revalidation: All cached data can define a revalidation interval, after which the data is marked as stale, triggering a re-fetch from origin
• On-demand revalidation: Any data can be triggered for revalidation on-demand, regardless of the revalidation interval. The revalidation propagates to all regions within 300ms
• Tag-based revalidation: Next.js allows associating tags with data, which can be used to revalidate all data with the same tag at once with revalidateTag
• Ephemeral: Each cache has a storage limit. When a cache reaches this limit, Edgenivo evicts (removes) the entries that haven't been accessed recently to free up space for new entries

When you deploy a Next.js project that uses App Router to Edgenivo, data cache is automatically enabled to cache segment-level data alongside ISR.

type BlogPosts = Awaited<ReturnType<typeof getStaticProps>>['props']['blog'];
 
export default function Page({ blog }: { blog: BlogPosts }) {
  return (
    <main>
      <pre>{JSON.stringify(blog, null, 2)}</pre>
    </main>
  );
}
 
export async function getStaticProps() {
  const res = await fetch('https://api.vercel.app/blog');
  const blog = await res.json();
 
  return {
    props: {
      blog,
    },
    revalidate: 3600, // 1 hour
  };
}

export default function Page({ blog }) {
  return (
    <main>
      <pre>{JSON.stringify(blog, null, 2)}</pre>
    </main>
  );
}
 
export async function getStaticProps() {
  const res = await fetch('https://api.vercel.app/blog');
  const blog = await res.json();
 
  return {
    props: {
      blog,
    },
    revalidate: 3600, // 1 hour
  };
}

export default async function Page() {
  const res = await fetch('https://api.vercel.app/blog', {
    next: {
      revalidate: 3600, // 1 hour
    },
  });
  const data = await res.json();
 
  return (
    <main>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </main>
  );
}

export default async function Page() {
  const res = await fetch('https://api.vercel.app/blog', {
    next: {
      revalidate: 3600, // 1 hour
    },
  });
  const data = await res.json();
 
  return (
    <main>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </main>
  );
}

export default async function Page() {
  const res = await fetch('https://api.vercel.app/blog', {
    next: {
      tags: ['blog'], // Invalidate with revalidateTag('blog') on-demand
    },
  });
  const data = await res.json();
 
  return '...';
}

export default async function Page() {
  const res = await fetch('https://api.vercel.app/blog', {
    next: {
      tags: ['blog'], // Invalidate with revalidateTag('blog') on-demand
    },
  });
  const data = await res.json();
 
  return '...';
}

'use server';
 
import { revalidateTag } from 'next/cache';
 
export default async function action() {
  revalidateTag('blog');
}

'use server';
 
import { revalidateTag } from 'next/cache';
 
export default async function action() {
  revalidateTag('blog');
}

Edgenivo persists cached data across deployments, unless you explicitly invalidate it using framework APIs like res.revalidate, revalidateTag, and revalidatePath, or by manually purging the cache. Cache is not updated at build time. When invalidated, Edgenivo updates the data at run time, triggered by the next request to the invalidated path.

When the system triggers a revalidation, Edgenivo marks the corresponding path or cache tag as stale in every region. The next request to that path or tag, regardless of the region, initiates revalidation and updates the cache globally. Edgenivo purges and updates the regional cache in all regions within 300ms.

CDN cache and Data cache are different cache layers. CDN cache stores full HTTP responses, while Data cache stores Next.js data fetch results.

To purge Data cache from the dashboard:

1. Under your project, open CDN in the sidebar.
2. In the sidebar, select Caches.
3. In the Purge cache section, select All content.
4. Under From which cache layer?, select Runtime and Data Cache.
5. Click Purge, then confirm in the modal.

In Purge history, this action is logged as a runtime cache purge event.

Purging your data cache will create a temporary increase in request times for users as new data needs to be refetched.

You can observe your project's data cache usage in Runtime Cache under Observability in your project sidebar. The Runtime Cache page provides visibility into what's stored in your project's data cache, along with insights like cache hit rate, cache reads, cache writes, and tag revalidations.

The Cache Hit Rate chart counts only fresh hits. The Hit Rate column in the entries and tags tables counts every read that didn't miss the cache, including stale and revalidated reads, so it can be higher than the chart for the same period.

You can also track data cache usage per request in Logs, under request metrics.

On-demand revalidation calls made from your functions, such as revalidateTag(), revalidatePath(), and expireTag(), are rate limited per plan:

The limit counts calls, not tags. It's averaged over a 30-second window, so short bursts above it are allowed. When you exceed it, the call fails with an HTTP 429 response that includes a retry-after header, and the cache is left unchanged. Retry the call after that delay.

Your plan determines whether your projects share a single data cache or whether each project gets its own:

Every plan splits the cache by deployment environment, so production and preview never share cached data. Data cache and Runtime Cache also use separate storage, so they don't compete for the same space.

When your projects share a cache, they share its storage limit and its eviction policy. A project that writes a lot of data can evict entries that belong to your other projects.

Every data cache has a fixed storage limit. When a cache reaches this limit, Edgenivo uses a least recently used (LRU) eviction policy: it removes the entries that haven't been accessed recently first. You can monitor your cache size and eviction activity in the Runtime Cache section of Observability section in the sidebar under your project.

Data cache works alongside Incremental Static Regeneration (ISR) and CDN Cache:

When a page contains entirely static data, Edgenivo uses ISR to generate the whole page. When a page contains a mix of static and dynamic data, the dynamic data is re-fetched when rendering the page. Data cache stores the static portion to avoid slow origin fetches.

Both Data cache and ISR support time-based revalidation, on-demand revalidation, and tag-based revalidation.

• Explore Edgenivo regions
• Next.js App Router template
• Learn how Data cache works in Next.js