Quick Summary: Next.js “use cache” directives often fail on Vercel due to missing experimental flags or version mismatches; here are three ways to force your deployment to actually cache data before your database bill skyrockets.

Next.js “use cache” Not Working on Vercel? Let’s Debug Production.

I still remember the first time I fully trusted a “magic” Next.js feature without verifying the logs. It was a Tuesday, deployment day for a client’s analytics dashboard. Local development was blazing fast—0ms latency on repeated reloads. “It works on my machine,” I told the Junior Dev, smugly sipping my lukewarm coffee.

Ten minutes after merging to main, prod-db-01 CPU usage spiked to 98%. The dashboard wasn’t caching anything. Every single user refresh was hammering the database with heavy aggregation queries. We were running in strict dynamic mode, and Vercel was ignoring the cache directive entirely. That night taught me a valuable lesson: Directives are suggestions until you configure the infrastructure to enforce them.

If you are staring at your Vercel logs wondering why your function execution time is 800ms instead of 50ms, you aren’t alone. Let’s fix this.

The Root Cause: It’s Experimental for a Reason

The "use cache" directive is part of the new Dynamic I/O architecture. It’s fantastic when it works, but here is the ugly truth: Vercel’s build pipeline often defaults to “safe” behavior. If the build system detects any ambiguity—headers, cookies, or search params being accessed outside of a suspense boundary—it often bails out of caching silently and opts for dynamic rendering to prevent serving stale data.

Furthermore, because this feature is technically still bleeding-edge (often requiring Canary builds), the default Vercel builder doesn’t always know how to optimize the lambda for it unless you explicitly tell it to.

Solution 1: The Quick Fix (The Configuration Flags)

Most of the time, this happens because you are using the directive in code, but you haven’t enabled the experimental flag that tells the compiler how to handle it during the build step. Without this, "use cache" is effectively a stripped comment.

Open your next.config.js or next.config.mjs. You need to explicitly opt-in to dynamicIO.

/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    // This is the magic switch you are likely missing
    dynamicIO: true,
    
    // Optional: If you are using PPR (Partial Prerendering), 
    // it often plays nicer with cache directives
    ppr: 'incremental',
  },
};

export default nextConfig;

Pro Tip: After pushing this change, go to your Vercel dashboard and manually redeploy without cache. Sometimes the build cache holds onto the old configuration artifacts.

Solution 2: The Permanent Fix (Use unstable_cache)

If the "use cache" directive feels too “magic” or flaky—which, in my experience, it can be on complex deployments—I recommend dropping down a level. The "use cache" directive is essentially syntactic sugar over the unstable_cache API.

Using the API directly gives you granular control over tags and revalidation times, and it tends to be much more robust in Vercel’s serverless environment right now. It’s less “clean” to look at, but it works every time.

import { unstable_cache } from 'next/cache';
import { db } from '@/lib/db';

// Instead of "use cache" at the top of the file...
// Wrap your heavy logic like this:

const getDashboardStats = unstable_cache(
  async (userId) => {
    console.log('Fetching stats from DB...'); // You should only see this once
    return await db.stats.findMany({ where: { userId } });
  },
  ['dashboard-stats'], // Uniqueness keys
  {
    revalidate: 3600, // Cache for 1 hour
    tags: ['stats']   // For on-demand invalidation
  }
);

export default async function Page({ params }) {
  const data = await getDashboardStats(params.id);
  return <div>{data.count}</div>;
}

Solution 3: The “Nuclear” Option (Manual KV)

Sometimes, the framework fights you. Maybe you have middleware conflicts, or weird edge-config issues. If you need caching right now and Vercel’s filesystem cache is ghosting you, bypass the framework entirely.

I call this the “Nuclear Option” because it adds external dependencies, but it saves production databases. We use Vercel KV (Redis) to manually wrap the call. It’s ugly, it’s manual, but it guarantees you control the cache hit/miss logic.

import { kv } from '@vercel/kv';

export async function getCachedData(key) {
  // 1. Try to get data from Redis
  const cached = await kv.get(key);
  
  if (cached) {
    console.log('HIT: Serving from Redis');
    return cached;
  }

  // 2. MISS: Hit the database
  console.log('MISS: Hitting prod-db-01');
  const freshData = await fetchExpensiveData();

  // 3. Set the cache manually (expire in 1 hour)
  await kv.set(key, freshData, { ex: 3600 });

  return freshData;
}

Comparison of Approaches

My advice? Start with the Config Flag. If dynamicIO doesn’t solve it, refactor the critical path to use unstable_cache. Save the Redis wrapper for when you’re truly desperate.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions