Web Design and Engineering

TanStack in 2026: Query, Router, Start, and what each one solves

TanStack Query passes 12M weekly downloads. The family now spans routing, tables, forms, and a full-stack framework. What each solves, and when to add it.

July 14, 20266 min read
Workshop wall with tools and workbench

TanStack is a family of headless, framework-agnostic libraries that each solve one hard frontend problem: server state, routing, tables, forms, virtualization, and now a full-stack framework. You install only the pieces you need. Nothing in the set assumes you use the rest, which is why a Next.js team and a Vue team can reach for the same tools.

The name comes from Tanner Linsley, who built TanStack Query (then React Query) in 2019. Seven years later the same idea, headless logic with no opinion about your UI, runs across eight libraries. If you build data-heavy React apps, dashboards, admin panels, internal tools, you have probably already shipped one of them.

The 30-second version

Start with Query. It manages the data that lives on your server. Add Router if you are starting a new app and want type-safe navigation. Add Table, Form, or Virtual when you hit the specific problem each one solves. Reach for Start only if you want a Vite-based full-stack framework in place of Next.js. Everything else (Store, DB, AI) is younger and worth watching before you bet a production app on it.

Why a set of separate libraries instead of one framework?

Most frontend tools ship logic and UI welded together. A date picker comes with its own markup and styles. TanStack does the opposite. Each library ships the logic (caching, sorting, validation, focus handling) and hands you the state, then gets out of the way. You render the markup with your own components and your own design system.

That has one cost and one benefit. The cost: you write more glue code than you would with a batteries-included widget. The benefit: the library never fights your design system, and the same core works in React, Vue, Solid, Angular, and Svelte. For a studio that ships a custom design system on every project, headless is the reason we keep coming back.

The libraries, one by one

TanStack Query: server state without the boilerplate

Query is where most teams find TanStack. It caches every server response, dedupes concurrent requests for the same data, refetches stale data in the background, and hands you loading and error states for free. In practice it removes the hundreds of lines of useEffect, loading flags, and manual cache code that a typical fetch layer accumulates.

It passes 12 million weekly npm downloads in early 2026, which makes it the default answer to server state in React. One thing it is not: a replacement for Redux or Zustand. Query owns server state. Your client state (a modal open flag, a form draft, a theme choice) still needs a small store. The two solve different problems and coexist happily.

TanStack Router: routing the compiler can check

Router ties your URL params, search params, loader data, and links to one generated route tree, all type-checked at build time. Rename a route or change a param and TypeScript flags every broken link before you run the app. One team reported that a URL refactor across a large codebase dropped from a half-day manual audit to a ten-second type check.

Next.js file routing works, but its type safety is thin: an editor plugin for link hints, not a compile-time guarantee. If your product is a dashboard with deep, parameterized URLs, Router earns its place. It is also the foundation the full-stack framework builds on.

TanStack Start: the Vite-based full-stack option

Start reached v1.0 in March 2026. It sits on Vite and TanStack Router and adds SSR, server functions, and streaming. The model is client-first with optional server rendering, the reverse of Next.js, which is server-first and asks you to opt into client behavior with 'use client'. Start deploys anywhere Nitro runs, so you are not tied to one host.

It won Breakthrough of the Year at the 2026 Open Source Awards, which signals momentum, not maturity. Start is stable but young. For a content-heavy marketing site, or a team already deep in the Next.js and Vercel workflow, Next.js stays the safer, more staffable pick. We covered the fuller trade-off in our Next.js 16 breakdown.

Table, Form, and Virtual: the tested middle

Table is a headless engine for sorting, filtering, grouping, and pagination that you wire to your own table markup. Virtual renders only the rows visible on screen, which keeps a 100,000-row list smooth. Form reached v1 and covers React, Vue, Angular, Solid, and Lit with type-safe validation. All three are production-ready and have been for a while. Add them the day you hit the problem they solve, not before.

Store, DB, and AI: watch, don't bet yet

Store is the small reactive core the other libraries lean on, useful on its own for lightweight client state. DB is newer: a client-side database built on differential dataflow that plugs into your existing useQuery calls, still pre-1.0 at v0.6. AI is the youngest, and won AI Project of the Year at the same 2026 awards. These are worth a prototype. They are not worth a production dependency until they settle.

How to adopt it without a big rewrite

You do not migrate to TanStack. You add one library at a time. The common path: drop Query into an existing app, wrap one screen's data fetching in a useQuery hook, and delete the useEffect and loading state it replaces. Ship that. Measure. If the app is new and routing-heavy, scaffold it on Router next. Tables and forms come later, screen by screen, wherever the hand-rolled version has started to hurt.

This incremental path is the whole point of a headless, single-purpose design. Each library stands alone, so you are never forced into an all-or-nothing rewrite to get value from one piece. A team can run Query in production for a year and never touch the rest of the set.

When TanStack fits, and when it doesn't

Reach for the TanStack libraries when your app is data-heavy and interactive: dashboards, SaaS back offices, internal tools, anything with tables and forms over live server data. The headless design pays off most when you run a custom design system and want full control of the markup.

Use less of it when your site is mostly static content. A marketing site or a blog does not need Query or Router. Server components and a simple fetch will do. And do not adopt the whole set on day one. The maintainers say it plainly: start with Query, add Router on a fresh build, add the rest only when a real pain point shows up.

Where this sits next to the rest of your stack

Query pairs with your framework, it does not replace it. You can run it inside Next.js today and add Router later, or never. If you are choosing a rendering model first, our decision tree for server versus client components is the better starting point. And the same discipline that makes Router worth it, catching mistakes at compile time, is why we keep strict mode on across every project.

Sources

Photo by camera obscura on Unsplash

Frequently asked questions

Does TanStack Query replace Redux or Zustand?
No. Query manages server state: data that lives on a remote API and needs fetching, caching, and syncing. Redux and Zustand manage client state: a modal flag, a wizard step, an unsaved form draft. Most apps need both. In practice, adding Query shrinks your global store a lot, because most of what teams used to keep in Redux was really cached server data. What remains is genuine UI state, and a small store handles that fine.
Can I use TanStack Query with Next.js?
Yes, and many teams do. Query runs inside a Next.js app alongside server components. You prefetch on the server, dehydrate the cache, and hydrate it on the client so the data is there on first paint. You do not need TanStack Router or Start to use Query. This is the most common adoption path: keep your Next.js app, add Query for client-side data fetching, and stop there if the rest of the set does not solve a problem you have.
Is TanStack Start ready to replace Next.js in production?
Start hit v1.0 in March 2026, so it is stable, not experimental. It is a strong pick for dashboards, SaaS back offices, and internal tools where type-safe routing and Vite build speed matter more than a large plugin market. For content-heavy marketing sites, and for teams that need to hire against a well-known stack, Next.js is still the safer default: more documentation, more developers who already know it, and a deeper set of integrations. Choose Start deliberately, not because it is new.

Studio

Start a project.

One partner for the digital product you need to build. Faster delivery, modern tech, lower costs. One team, one invoice.