TanStack Query vs SWR in 2026: Which Data Fetching Library Wins?

TanStack Query has 12.3 million weekly downloads. SWR has 7.7 million. Two years ago, SWR was ahead. The trend is clear — and it tells a bigger story about what developers want from their data fetching layer.

Both libraries solve the same core problem: fetching, caching, and synchronizing server state in React applications. But they take fundamentally different approaches to how much they handle for you. We compared them using real-time data from PkgPulse across five dimensions that actually matter.

Here's what the data says.

At a Glance: The Numbers

| Metric | TanStack Query | SWR | |--------|---------------|-----| | Weekly Downloads | 12.3M | 7.7M | | Bundle Size (min+gzip) | ~13.4KB | ~4.2KB | | GitHub Stars | 44K+ | 30K+ | | First Release | 2019 | 2019 | | Current Version | 5.x | 2.x | | TypeScript | Built-in | Built-in | | Creator | Tanner Linsley | Vercel | | License | MIT | MIT |

See the full live comparison — health scores, download trends, and more — at pkgpulse.com/compare/@tanstack/react-query-vs-swr

The headline stat: TanStack Query's weekly downloads have grown roughly 60% year-over-year, overtaking SWR in late 2024 and widening the gap since. But SWR's 7.7M downloads still represent a massive, healthy ecosystem — particularly in the Next.js world where it's a first-party recommendation.

Bundle Size: SWR's Clear Advantage

SWR weighs in at 4.2KB gzipped. TanStack Query is 13.4KB. That's a 3x difference.

For most applications, 13KB won't be your bottleneck — your images, fonts, and third-party scripts dwarf that. But if you're building a lightweight app where every kilobyte counts, SWR's minimal footprint is a real advantage.

TanStack Query's extra weight buys you more built-in features: devtools, mutation handling, query invalidation patterns, and pagination primitives. Whether that trade-off is worth it depends on your project's complexity.

The takeaway: SWR is leaner by design. TanStack Query is heavier because it does more out of the box. Neither is wrong — they're optimizing for different things.

Caching and Stale Data Management

This is where the libraries diverge most.

SWR: Stale-While-Revalidate

SWR's name is its philosophy. It returns cached (stale) data immediately, then revalidates in the background. The API is deliberately minimal:

import useSWR from 'swr'

const fetcher = (url: string) => fetch(url).then(r => r.json())

function Profile() {
  const { data, error, isLoading } = useSWR('/api/user', fetcher)
  if (error) return <div>Failed to load</div>
  if (isLoading) return <div>Loading...</div>
  return <div>Hello, {data.name}</div>
}

Simple. The cache key is the URL. The fetcher is yours. SWR handles the rest — revalidation on focus, revalidation on reconnect, polling intervals. You can configure these, but the defaults are sensible.

TanStack Query: Full Server State Management

TanStack Query treats server state as a first-class concern with explicit lifecycle management:

import { useQuery } from '@tanstack/react-query'

function Profile() {
  const { data, error, isLoading, isFetching } = useQuery({
    queryKey: ['user'],
    queryFn: () => fetch('/api/user').then(r => r.json()),
    staleTime: 5 * 60 * 1000, // 5 minutes
    gcTime: 30 * 60 * 1000,   // garbage collect after 30 min
    retry: 3,
    refetchOnWindowFocus: true,
  })
  // ...
}

More configuration surface — but also more control. You define exactly when data goes stale, when it's garbage collected, how retries work, and how background refetches behave. For complex apps with many interdependent queries, this explicitness pays off.

The trade-off: SWR is simpler to adopt. TanStack Query gives you more levers to pull when you need them.

Mutations: The Biggest Gap

Mutations are where TanStack Query pulls ahead decisively.

SWR Mutations

SWR added useSWRMutation in v2, but it's relatively basic:

import useSWRMutation from 'swr/mutation'

const { trigger, isMutating } = useSWRMutation('/api/user', updateUser)

It works, but cache invalidation after mutations requires manual coordination. There's no built-in optimistic update pattern — you manage that yourself.

TanStack Query Mutations

TanStack Query's useMutation is a full mutation management system:

import { useMutation, useQueryClient } from '@tanstack/react-query'

const queryClient = useQueryClient()

const mutation = useMutation({
  mutationFn: updateUser,
  onMutate: async (newUser) => {
    // Cancel in-flight queries
    await queryClient.cancelQueries({ queryKey: ['user'] })
    // Snapshot previous value
    const previous = queryClient.getQueryData(['user'])
    // Optimistic update
    queryClient.setQueryData(['user'], newUser)
    return { previous }
  },
  onError: (err, newUser, context) => {
    // Rollback on error
    queryClient.setQueryData(['user'], context.previous)
  },
  onSettled: () => {
    queryClient.invalidateQueries({ queryKey: ['user'] })
  },
})

Optimistic updates, rollback on failure, automatic cache invalidation — all built in. For apps with heavy write operations, this is a significant productivity gain.

Developer Experience and Tooling

DevTools

TanStack Query ships dedicated devtools that show every query's state, cache status, timing, and dependencies in a floating panel. They're invaluable for debugging cache issues. SWR has community devtools, but nothing as polished or official.

TypeScript Support

Both have excellent TypeScript support. TanStack Query v5 improved type inference significantly — query functions automatically type the response data without manual generics in most cases. SWR's types are solid but require more manual annotation for complex use cases.

Learning Curve

SWR wins here. You can be productive in 10 minutes. The API surface is small, the docs are clear, and the defaults handle most scenarios. TanStack Query has more concepts to internalize — query keys, stale time, gc time, mutation lifecycle — but the payoff is more control over complex scenarios.

Framework Support

TanStack Query is framework-agnostic. There are official adapters for React, Vue, Solid, Svelte, and Angular. SWR is React-only by design (with community ports). If you might move beyond React, TanStack Query provides a smoother path.

Server-Side Rendering and Next.js

Both libraries work with Next.js, but with different levels of integration.

SWR has first-party Vercel support. It integrates cleanly with Next.js app router and server components. The SWRConfig provider handles initial data hydration:

<SWRConfig value={{ fallback: { '/api/user': userData } }}>
  <App />
</SWRConfig>

TanStack Query requires slightly more setup for SSR — HydrationBoundary, dehydrate, and query prefetching on the server. More boilerplate, but also more explicit control over what gets pre-fetched and how it hydrates.

For Next.js-heavy teams, SWR's tighter Vercel integration is a legitimate advantage. For other frameworks or custom SSR setups, TanStack Query's explicit approach is often cleaner.

When to Choose TanStack Query

Your app has complex mutations — optimistic updates, rollbacks, and cache invalidation are first-class features
You need devtools — the official devtools panel is the best in class for debugging cache issues
You're not locked to React — TanStack Query supports Vue, Solid, Svelte, and Angular
You have many interdependent queries — explicit cache keys and invalidation patterns handle complex dependency graphs
You want full control — stale time, gc time, retry logic, and refetch policies are all configurable per-query

When to Choose SWR

You're building with Next.js and want the tightest integration with the Vercel ecosystem
Your app is read-heavy with simple mutations — SWR's stale-while-revalidate pattern excels here
Bundle size matters — at 4.2KB, SWR is 3x smaller
You value simplicity — fewer concepts to learn, faster onboarding for new team members
You want convention over configuration — SWR's defaults are right for most use cases

The Verdict

TanStack Query has earned its download lead. For applications with complex server state — mutations, optimistic updates, cache invalidation, dependent queries — it's the more capable tool. The devtools alone justify the switch for many teams.

SWR remains the pragmatic choice for read-heavy applications, Next.js projects, and teams that value a minimal API surface. It does less, but what it does, it does cleanly.

The trend is moving toward TanStack Query, but SWR isn't going anywhere. Both are actively maintained, well-documented, and production-proven at scale.

Compare TanStack Query vs SWR on PkgPulse →

Frequently Asked Questions

Is TanStack Query better than SWR?

TanStack Query offers more features — particularly around mutations, devtools, and multi-framework support. SWR is lighter and simpler with tighter Next.js integration. For complex apps with heavy write operations, TanStack Query is typically the better choice. For read-heavy apps or Next.js projects, SWR is often sufficient. Check the full comparison on PkgPulse for real-time download data.

Can I use TanStack Query with Next.js?

Yes. TanStack Query works with Next.js app router and server components, though it requires more setup than SWR — specifically HydrationBoundary and server-side query prefetching. SWR has slightly tighter integration since both are Vercel projects, but TanStack Query is fully compatible and widely used in Next.js applications.

What is the difference between SWR and TanStack Query for mutations?

TanStack Query has a dedicated useMutation hook with built-in optimistic updates, rollback on failure, automatic cache invalidation, and mutation lifecycle callbacks (onMutate, onError, onSettled). SWR added useSWRMutation in v2, which handles basic mutations but requires more manual work for optimistic updates and cache coordination.

Explore more comparisons: React Query vs Apollo Client, SWR vs Axios, or tRPC vs React Query on PkgPulse.

Stay Updated