Next.js 16+ · Function

unstable_noStore

unstable_noStore() opts a component out of prerendering and caching. It is deprecated in favor of connection() and should mainly be retained for existing code.

Since: 14.0.0

How it works

Call unstable_noStore() inside a Server Component before request-specific or uncached work. It opts that component out of prerendering and caching, providing a granular alternative to route-wide dynamic configuration; in current Next.js, connection() is the recommended replacement when request-time rendering is required.

Syntax

unstable_noStore(): void

Returns

void

Key points

Calling the function marks the current component as dynamic rather than allowing it to be prerendered.
Its scope is the component where it is called, enabling targeted uncached rendering.
It provides fetch-like no-store behavior without adding cache options to a fetch call.
The component-level API is more precise than forcing dynamic rendering for the entire route.
Use it when avoiding fetch configuration is desirable or when the data source is not fetch-based.

Common mistakes

Calling it inside unstable_cache does not override that cache scope; the enclosing cache configuration controls whether the result is cached.
Do not use it to bypass an existing unstable_cache configuration.

Example: Opt a Server Component out of caching

import { unstable_noStore as noStore } from 'next/cache'

export default async function Page() {
  noStore()
  const data = await db.query('SELECT * FROM products')
  return <pre>{JSON.stringify(data, null, 2)}</pre>
}

This Server Component opts its database-backed rendering out of prerendering and caching.

When to use it

Uncached data access

A Server Component reads directly from a database or another data source that does not use fetch caching options.

Granular dynamic rendering

Only one component needs dynamic behavior while the rest of the route can remain statically optimized.

Migrating older code

Existing code needs an explicit compatibility replacement for fetch no-store behavior.

Interview questions

QWhat does unstable_noStore do?

unstable_noStore() declaratively opts a component out of prerendering and indicates that the component should not be cached. It is more granular than setting force-dynamic for the whole route and can be used where the uncached behavior is needed.

Follow-up: What should new code use instead? Use connection() when dynamic rendering is required, because the documentation recommends it as the replacement.

QWhen would you use unstable_noStore instead of fetch cache options?

It is a replacement for fetch options such as cache: 'no-store' and next: { revalidate: 0 }, and it is useful when fetch is unavailable. The call is made directly in the component before the uncached work.

Follow-up: Does it override unstable_cache? No; inside unstable_cache, the cache configuration remains authoritative.

QWhat is its version status?

The function was introduced in version 14.0.0 and deprecated in version 15.0.0 in favor of connection(). Although still documented, it should generally be treated as a compatibility API rather than the preferred choice for new implementations.

Follow-up: Why might it still appear in existing applications? Existing code may use it for component-level opt-out behavior, but migration to connection() is the current direction.

connection
unstable_cache
fetch
export const dynamic = 'force-dynamic'

Source: unstable_noStore. Checked 2026-10-15.