Skip to content

TanStack Query

★ New
adopt
Frontend open-source MIT open-source

At a Glance

Async server-state management and data-fetching library for React (and other frameworks) with automatic caching, background refresh, and optimistic updates; ~12–16M weekly npm downloads.

Type
open-source
Pricing
open-source
License
MIT
Adoption fit
small, medium, enterprise
Top alternatives

What It Does

TanStack Query (formerly React Query) manages async server state in frontend applications. It provides a declarative, hook-based API for fetching, caching, synchronizing, and updating remote data without requiring global client-side stores for server state. The core insight is separating “server state” (data owned by a remote source) from “client state” (data owned by the UI), a distinction most state management solutions blur.

Out of the box it handles cache invalidation, background refetching, stale-while-revalidate, pagination, infinite scrolling, optimistic mutations, and request deduplication. It does not prescribe a fetching mechanism — you bring your own fetch/axios/tRPC call.

Key Features

  • Automatic background refetching on window focus and reconnect, with configurable stale time and cache time
  • Query deduplication — multiple components requesting the same query key share a single in-flight request
  • Optimistic mutations with automatic rollback on failure
  • Infinite queries with useInfiniteQuery; v5 adds maxPages to cap memory growth (90% reduction in long sessions)
  • SSR/hydration support via dehydrate/hydrate for Next.js, TanStack Start, Remix
  • Devtools as a separate package (tree-shakeable; must ensure excluded from production bundles)
  • Framework adapters: React, Vue, Solid, Svelte, Angular — React adapter is by far the most mature
  • ESLint plugin with rules enforcing correct query key patterns and exhaustive dependencies
  • Persistence plugins for offline-capable apps via localStorage or IndexedDB

Use Cases

  • Use case 1: REST/GraphQL data fetching in React SPAs where manual useEffect-based fetching has become unmaintainable
  • Use case 2: Apps requiring optimistic UI (mutations show immediately, roll back on error) without complex state machinery
  • Use case 3: Dashboards needing auto-refreshing data with staleness controls (analytics, monitoring UIs)
  • Use case 4: Infinite scroll feeds or paginated lists where coordinating page state is error-prone by hand
  • Use case 5: SSR applications where server-fetched data needs to be dehydrated and rehydrated on the client

Adoption Level Analysis

Small teams (<20 engineers): Fits well. Eliminates entire categories of data-fetching boilerplate. Low setup cost; works with any fetching library. Default configuration is sensible for most small applications.

Medium orgs (20–200 engineers): Strong fit. Standardizes data-fetching patterns across teams. The ESLint plugin and DevTools improve debuggability at scale. The v4→v5 migration is a real cost (~3,800 words of breaking changes) — teams should evaluate version upgrade cadence as a recurring investment.

Enterprise (200+ engineers): Fits with caveats. Widely deployed in large React codebases. The lack of first-party server-side caching (you still need a backend cache) means TanStack Query solves client-side staleness, not origin load. Teams operating in non-React ecosystems (Vue, Angular) get a degraded feature set with slower-maturing adapters.

Alternatives

AlternativeKey DifferencePrefer when…
SWR (Vercel)Simpler API, smaller bundle, fewer featuresVercel/Next.js-first teams wanting minimal API surface
Apollo ClientIncludes a full GraphQL client + normalized cacheAll queries are GraphQL and you want normalized entity cache
RTK Query (Redux Toolkit)Tightly integrated with Redux ecosystemTeam already uses Redux and wants one state management solution
React Router loadersData loading baked into routing (React Router v6.4+)Remix/React Router-first apps where data co-locates with routes
tRPCEnd-to-end type-safe RPC, often used alongside TanStack QueryTypeScript full-stack monorepos wanting zero-schema API contracts

Evidence & Sources

Notes & Caveats

  • v4→v5 breaking changes: Significant refactor required. Every useQuery call signature changed. Private class fields in v5 break patterns that previously relied on TypeScript-only access control.
  • DevTools bundle size: DevTools package must be explicitly excluded from production builds; there was a bug in v5 alpha where it was inadvertently included. Verify your bundler tree-shakes it.
  • Not a replacement for server-side caching: TanStack Query manages client-side staleness. For high-traffic applications, backend caching (Redis, CDN) is still required. TanStack Query can worsen origin load if staleTime is configured too aggressively short across many users.
  • Framework adapter depth inequality: React adapter is the reference implementation. Vue Query is solid; Svelte/Angular adapters have fewer contributors and may lag in features or bug fixes.
  • Sustainability: Funded via sponsorship (no VC, no paid tier). 16 corporate sponsors. Single BDFL (Tanner Linsley). If corporate sponsors reduce funding, maintenance velocity may slow. No enterprise support contract available.

Related