React Query vs SWR: Full-Featured Cache vs Lightweight Fetching

Overview

React Query (now TanStack Query) and SWR are both server state management libraries for React, built on the stale-while-revalidate caching strategy. Both libraries take the position that server state (data fetched from APIs) is fundamentally different from client state (UI state) and deserves its own management layer with caching, background refetching, and deduplication. SWR was created by Vercel in 2019, taking a minimal philosophy. React Query, created by Tanner Linsley, emerged as a more feature-complete alternative with a richer API.

For most modern React applications, the recommendation is the same: stop putting server data in Redux or useState/useEffect chains and use a dedicated server state library. The choice between React Query and SWR comes down to how much feature depth you need versus how small your dependencies should be.

Key Technical Differences

React Query's useMutation hook is one of its clearest advantages over SWR. It provides a complete lifecycle for write operations — loading state, error handling, onSuccess/onError callbacks, and built-in optimistic update patterns. The queryClient.invalidateQueries API lets you precisely control cache invalidation after mutations, so that relevant data is refetched automatically. In SWR, mutations and cache invalidation require more manual orchestration.

SWR's core API is deliberately minimal: const { data, error, isLoading } = useSWR(key, fetcher). The key can be a string, array, or function (null key disables fetching). The fetcher is any async function. SWR handles deduplication, revalidation on focus, revalidation on network reconnect, and interval polling with configuration options. For a large class of applications — read-heavy dashboards, user profile pages, content displays — SWR's minimal API is sufficient.

React Query's devtools are genuinely excellent. A collapsible panel shows every active query, its cache state, its data, and its last fetch time. You can trigger refetches, inspect cache contents, and observe background refresh behavior in real time. SWR has no official devtools, which makes debugging cache-related issues more difficult.

Performance & Scale

Both libraries use the same fundamental optimization: request deduplication (multiple components using the same query key share one network request) and background revalidation. React Query's normalized caching (available in React Query v5) allows sharing cached data across different query keys, reducing duplicate API calls for related data. SWR's simpler cache model is more predictable but less optimizable for complex data relationships.

When to Choose Each

Choose React Query for applications with complex server state requirements — apps with significant mutation patterns, optimistic updates, paginated/infinite scroll data, or interdependent queries with sophisticated invalidation logic. The devtools alone are worth the larger bundle size for applications in active development.

Choose SWR for applications with simpler data fetching patterns — primarily read-heavy UIs where the basic revalidation-on-focus semantics cover most use cases. If bundle size is a real concern or if you value extreme API simplicity, SWR's 4KB footprint and zero-config setup are compelling.

Bottom Line

React Query wins on feature depth, devtools, and mutation handling. SWR wins on bundle size and API minimalism. For most production applications with real CRUD patterns, React Query's full feature set justifies the additional size.