Skip to main content

Choosing Between SWR, RTK Query, and TanStack Query

Three libraries dominate React server-state management: SWR (Vercel's minimalist hook), RTK Query (Redux Toolkit's batteries-included solution), and TanStack Query (formerly React Query, the independent gold standard). Each solves caching, mutations, and invalidation, but with wildly different trade-offs. SWR wins on simplicity and bundle size; RTK Query on TypeScript and Redux integration; TanStack Query on features and framework-agnostic design. Choosing requires understanding your team's constraints, app complexity, and existing stack. This guide provides a decision framework and real-world criteria to pick confidently.

The Three Libraries at a Glance​

SWR is Vercel's lightweight hook library emphasizing the stale-while-revalidate HTTP pattern. It assumes your backend serves REST endpoints and handles the rest implicitly.

RTK Query is a comprehensive layer atop Redux, providing automatic cache normalization, optimistic updates, and deep DevTools integration. It's opinionated: you define endpoints upfront, and RTK Query orchestrates everything.

TanStack Query is the Swiss Army knife. Framework-agnostic (works in Vue, Svelte, Angular), it offers powerful features (infinite queries, background refetching, offline support) without forcing Redux.

FeatureSWRRTK QueryTanStack Query
Bundle size (min+gzip)~4 KB~20 KB~8 KB
Redux requiredNoYesNo
Auto type inferenceManualAutomaticManual (but powerful)
Optimistic updatesManualBuilt-inBuilt-in
Offline supportNoNo (manual)Yes (plugins)
Cache persistenceNoManualPlugins (localStorage, IndexedDB)
PollingConfig-basedConfig-basedAdvanced (background refetching)
Infinite queriesuseSWRInfinite hookWorkaround (compose endpoints)Native support
DevToolsBasic loggingFull Redux DevToolsStandalone DevTools
Learning curveMinimalModerateLow-to-moderate
Community pluginsFewMany (Redux ecosystem)Extensive
Suitable forStartups, small appsTeams using ReduxFeature-rich data-heavy apps

Decision Framework​

Ask these questions in order:

1. Are you already using Redux?​

  • Yes → RTK Query is a natural fit. It integrates seamlessly and provides automatic type inference.
  • No → SWR or TanStack Query. Both work without Redux. SWR is simpler; TanStack Query is more powerful.

2. How many unique API endpoints will you have?​

  • <20 → SWR. Minimal boilerplate, great for small projects.
  • 20–50 → SWR or TanStack Query. Both scale well; TanStack Query's features shine with heterogeneous endpoints.
  • >50 → RTK Query or TanStack Query. Both provide structure to manage complexity.

3. Do you need advanced features (offline, infinite scroll, background refetch)?​

  • Yes → TanStack Query. It's built for these; RTK Query and SWR require manual workarounds.
  • No → SWR or RTK Query suffice.

4. Is bundle size critical?​

  • Yes (IoT, embedded, low-end devices) → SWR (~4 KB). Non-negotiable.
  • No → RTK Query or TanStack Query are worth the cost for their features.

5. How important is TypeScript type inference?​

  • Critical → RTK Query. Automatic inference from endpoint definitions eliminates manual typing.
  • Nice-to-have → TanStack Query with careful manual typing, or SWR with custom hooks.
  • Not important → Any of the three work in untyped JavaScript.

Real-World Scenarios​

Scenario 1: Solo developer, simple blog

  • SWR is ideal. Zero setup, one fetcher, write the blog in a day.
  • RTK Query is overkill; TanStack Query is a sledgehammer.
  • Decision: SWR.

Scenario 2: Early-stage startup, 3–5 engineers, MVP with 10–20 endpoints

  • SWR is tempting but will cause "forgot to revalidate" bugs as team grows.
  • TanStack Query or RTK Query both work; TanStack Query is simpler (no Redux).
  • Decision: TanStack Query. Invest in the right tool early; it pays dividends.

Scenario 3: Mature SaaS, 100+ endpoints, heavy Redux usage

  • RTK Query is the path of least resistance. Existing Redux knowledge, automatic inference, DevTools.
  • TanStack Query is a viable alternative if you want to move away from Redux.
  • SWR is too simple for this scale.
  • Decision: RTK Query.

Scenario 4: Data dashboard with real-time updates and offline mode

  • TanStack Query with WebSocket plugins and localStorage persistence.
  • RTK Query requires custom onCacheEntryAdded logic; possible but manual.
  • SWR is not suitable.
  • Decision: TanStack Query.

Scenario 5: Monorepo with Next.js, shared API types

  • All three work. RTK Query edges ahead if you want automatic TypeScript inference.
  • TanStack Query is equally good if you export types from your API package.
  • SWR works but requires manual typing across the monorepo.
  • Decision: RTK Query or TanStack Query (team preference).

Feature Comparison by Use Case​

Mutations and Optimistic Updates:

  • SWR: manual (you write rollback logic)
  • RTK Query: built-in (onQueryStarted)
  • TanStack Query: built-in (onMutate + onError)
  • Winner: TanStack Query and RTK Query tie.

Cache Invalidation:

  • SWR: implicit (URL-based), manual mutate() calls
  • RTK Query: explicit (tags), automatic invalidation
  • TanStack Query: explicit (query keys), powerful but requires discipline
  • Winner: RTK Query (safest).

Type Safety:

  • SWR: manual per-hook
  • RTK Query: automatic from endpoint
  • TanStack Query: manual but very flexible
  • Winner: RTK Query.

Learning Curve:

  • SWR: 30 minutes (one hook, one fetcher)
  • RTK Query: 2–3 hours (Redux setup, API slice pattern, tags)
  • TanStack Query: 1–2 hours (simpler than Redux, but more concepts than SWR)
  • Winner: SWR.

Ecosystem and Plugins:

  • SWR: minimal
  • RTK Query: large (entire Redux ecosystem)
  • TanStack Query: growing; official plugins for persistence, infinite queries, etc.
  • Winner: TanStack Query.

Migration Paths​

From SWR to TanStack Query:

  • Similar hook-based API; migration is straightforward (2–3 days for a small project).
  • Gain offline support, better error handling, more control.

From SWR to RTK Query:

  • Requires Redux setup and rewriting hooks as endpoints.
  • More friction (2+ weeks for a large project) but worth it if your team values Redux.

From RTK Query to TanStack Query:

  • RTK Query queries become useQuery(); mutations become useMutation().
  • Lose automatic type inference and Redux DevTools, but simplify the stack.
  • Not recommended for existing large codebases.

From any library to another:

  • Design your components to depend on custom hooks (useGetUser()) that abstract the library.
  • Change the hook implementation without touching components.

Hybrid Approach: Using Multiple Libraries​

In rare cases, using two libraries makes sense:

// Use SWR for read-heavy views (posts list, user profiles)
const { data: posts } = useSWR('/api/posts', fetcher);

// Use TanStack Query for complex mutations (payment flow)
const { mutate: processPayment } = useMutation({
  mutationFn: (payment) => fetch('/api/payments', { method: 'POST', body: JSON.stringify(payment) }),
  onSuccess: () => queryClient.invalidateQueries({ queryKey: ['user', 'billing'] }),
});

This is generally a bad idea—cognitive overhead is high, and bundle size balloons. Pick one and stick with it.

The 2026 Landscape​

As of June 2026, the consensus is:

  • SWR remains the lightweight choice for small, read-heavy projects. Vercel maintains it actively, but feature velocity is slow.
  • RTK Query has matured and is the default for Redux teams. RTK v2 added excellent developer ergonomics.
  • TanStack Query has become the dominant choice for teams building data-heavy apps without Redux. Its plugin ecosystem rivals React's entire state-management landscape.

For new projects without existing constraints, TanStack Query is the safe bet.

Key Takeaways​

  • SWR for simplicity and bundle size; startups and small projects.
  • RTK Query for TypeScript type inference and Redux integration; teams already using Redux.
  • TanStack Query for features, ecosystem, and framework-agnostic design; data-heavy applications.
  • No library is universally "best"—trade-offs depend on your constraints and team.
  • Invest in the right tool early; migration is costly.

Frequently Asked Questions​

Can I use RTK Query without Redux?​

RTK Query is built on Redux. You can use it without manually writing Redux code (RTK handles it), but it still requires Redux under the hood. If you want no Redux at all, choose SWR or TanStack Query.

Is SWR still maintained?​

Yes, actively. Vercel maintains it, and it receives bug fixes and minor improvements. Major features are rare—it's intentionally minimalist.

Which library has the best performance?​

All three are fast for typical use cases. SWR has the smallest bundle and lowest memory overhead. TanStack Query is highly optimized for re-renders. RTK Query's Redux store can be slower with 1000+ queries, but this is rare. Benchmark your app; the difference is negligible for most projects.

Can I use TanStack Query with Server Components in Next.js?​

TanStack Query is client-side only. For server components, use fetch() with revalidatePath() or revalidateTag(). You can mix server data with client TanStack Query queries.

Should I use RTK Query if I'm moving away from Redux?​

No. If you're actively trying to reduce Redux usage, choose TanStack Query. RTK Query ties you deeper into the Redux ecosystem.

Which library integrates best with TypeScript?​

RTK Query. Automatic type inference from endpoint definitions is a game-changer. TanStack Query is close but requires more manual typing.

Is GraphQL support important for choosing?​

SWR and TanStack Query both support GraphQL (your fetcher calls a GraphQL endpoint). RTK Query supports it via custom baseQuery. All three are GraphQL-capable; preference is personal.

Further Reading​