When fetching data from external sources like a database or CMS, it can be beneficial to prevent re-fetching the same data if it has not changed by utilizing caching. This guide will explain how to use the Next.js App Router and the Vercel Data Cache to persist cached data across deployments.
Copy link to headingRequirements
To cache data and share responses across deployments, you must currently use the Next.js App Router (latest version recommended). You cannot share the cache between different projects.
Copy link to headingNext.js App Router
The Next.js App Router (app/) provides more fine-grained control over fetching, caching, and revalidating your data. For example, you can fetch and cache data (using fetch or your favorite library) and revalidate the data by cache tag or path by defining a stale time or programmatically purging the cache.
Copy link to headingVercel Data Cache
The Vercel Data Cache is a specialized, granular cache for storing responses from fetches while using modern frontend frameworks like Next.js. It's a shared cache, meaning users of the same project share the same cache.
Frameworks that integrate with the Data Cache (currently Next.js) can cache data per fetch instead of per route. This means you can have static, dynamic, and revalidated data together in the same route.
Copy link to headingExample
Inside your Next.js application, fetch and tag your data with a cache key:
The response from fetch will be cached and not re-fetched on the next deployment. Instead, to revalidate the data and purge the cache, you can use revalidateTag:
Copy link to headingFrequently asked questions
What are the differences with build caching?
Caching data from your database, CMS, or other external location is different than caching artifacts during the build process.
Vercel's build cache will prevent re-downloading dependencies (node_modules), monorepo cache artifacts (remote cache), and framework-specific files.
What are the differences with Edge Network caching?
Static assets like images, fonts, and JavaScript files can be cached in Vercel's Edge Network regions from the deployment outputs created after a build. These files, typically generated by your framework, usually contain a hash in the filename.
The filename hash enables the ability to safely add immutable caching headers since we are guaranteed that a new version of the file will be generated by the framework if something changes. This also means these cached files will persist across deployments.
What are the differences with Incremental Static Regeneration?
When a page contains entirely static data, Vercel will use Incremental Static Regeneration (ISR) to generate the whole page. However, when a page contains a mix of static and dynamic data, the dynamic data needs to be re-fetched when rendering the page. In this scenario, the Vercel Data Cache is used to cache the static data to avoid slow origin fetches.
Both ISR and Vercel Data Cache support time-based revalidation, on-demand revalidation, and tag-based revalidation.