What is TanStack? It is probably already running in one of your projects without ever having been called that in a status report. If your front-end team at some point introduced ‘React Query’ to load and cache server data cleanly, that is TanStack Query today. The name has changed; the library has stayed the same. And it is huge: the React adapter alone is downloaded more than ten million times a week, which makes TanStack Query one of the most widely used front-end libraries of all.
Even so, the term causes confusion. TanStack sounds like yet another JavaScript framework competing with React, Vue or Angular. It is not. TanStack is a collection of open-source libraries for building modern web applications: headless, type-safe and, in most cases, framework-independent. They do not replace your framework; they add exactly the building blocks that every serious project ends up rebuilding itself sooner or later: data loading, routing, tables, forms, virtualisation.
This article explains what is behind the name, which libraries belong to the stack, which of them are production-ready and which are not, and why the topic also matters for e-commerce and headless commerce projects. Not a tutorial but the decision-maker’s perspective: what do I get, what do I risk, and when is it worth it?
What TanStack is, and what it is not
The most common misconception first: TanStack does not compete with React. It builds on it. You still choose your framework (React, Vue, Angular, Solid, Svelte), and TanStack supplies the functional layers that the framework deliberately leaves open. React takes care of rendering the interface. How you fetch server data, cache it and keep it in sync is not React’s job, and that is exactly the gap TanStack Query fills.
The second key term is headless. A headless library supplies the logic but no finished look. TanStack Table, for example, brings the complete mechanics of a data table, meaning sorting, filtering, pagination, column grouping and row selection, but not a single prefabricated pixel. Markup and styling stay entirely with you. For a team with its own design system, that is an advantage, because you do not inherit someone else’s look that you first have to laboriously override. For a team that needs a standard table quickly, it is extra work. So headless is not purely a plus but a conscious decision against a prefabricated look and in favour of full control.
The project is led by Tanner Linsley, who developed the collection from two libraries that were originally React-specific: React Query and React Table. When both dropped their React focus and were opened up to other frameworks, a new umbrella name was needed. ‘React Query’ became TanStack Query, ‘React Table’ became TanStack Table, and a whole family of libraries has joined since then. According to TanStack, companies including Google, Amazon, Microsoft, Apple and Walmart rely on parts of the stack in production today. That is not a marketing detail but a statement about risk: you are not building on a hobby project that could be abandoned next year. What TanStack explicitly is not, on the other hand: an off-the-shelf component set, a design system like Material UI or a hosted platform with a licence fee. It is open source under the MIT licence and can be used one building block at a time.
The four principles, and why they matter to decision-makers
TanStack consistently follows four guiding principles. They sound technical but have direct consequences for budget, risk and team set-up.
Framework-agnostic. Most of the libraries consist of a framework-neutral core plus thin adapters for React, Vue, Solid, Svelte and Angular. In practice this means: if your team switches front-end framework at some point, you take your knowledge of data and table handling with you instead of relearning it for each framework. That lowers the risk inherent in every technology decision that commits a team for years.
Type-safe from the ground up. TanStack is built consistently in TypeScript and carries type safety through to the edge cases where other tools give up, such as URL parameters or form fields. As a result, the compiler shows you every place you need to update when you restructure, rather than a customer finding the bug later in the checkout. Fewer runtime errors, safer refactoring and therefore maintenance costs that do not explode with every restructure.
Production-proven. The core libraries run in some of the largest web applications in the world. For an architecture decision, that is half the battle: you are not placing a bet but relying on code that is under real load and scaling pressure.
No vendor lock-in. Open source, independent, no platform tie-in. You can use a single library and ignore the rest, and you can just as easily remove it again. In concrete terms, the MIT licence means: commercial use is allowed, there is no fee and there is no vendor that changes its pricing model tomorrow. This freedom has a downside, which I will come back to under supply chain security.
An overview of the libraries
The stack now comprises more than a dozen libraries. You do not need to know them all. Three of them cover most real-world use cases; the rest are specialist tools. I will go through them by area of responsibility, starting with the most important.
Data and state
TanStack Query is the heart of the stack and the reason most teams come into contact with it in the first place. It solves a problem that seems trivial at first glance and in practice clutters entire codebases: loading, caching and updating server data. Without a tool like Query, every team sooner or later builds its own half-baked caching mechanism, with stale data, duplicate requests and loading states that nobody manages properly. Query takes this off your hands: it caches automatically, refetches in the background, retries failed requests and keeps the interface consistent. It supports React, Vue, Solid, Svelte, Angular and Lit. If you use only one library from the stack, it is very likely to be this one.
TanStack DB goes a step further and is the most exciting newcomer. It is a reactive, client-side data store that builds on Query and is based on what is known as differential dataflow. Put simply: the interface stays fast and consistent even when a lot of data is involved, because only the actual changes are recalculated rather than everything. DB is still in beta, however, so it is interesting for prototypes but not yet the default for a business-critical system.
There are also TanStack Store (a lean, reactive state container that powers many of the other libraries internally) and TanStack AI (an open SDK with a uniform interface to various AI providers, without lock-in to a single provider). Both are in alpha and better suited to teams that want to experiment early.
Routing and full stack
TanStack Router is a type-safe router, and type safety is the entire selling point here. It generates a fully typed route tree at build time: every path parameter, every search parameter in the URL and every loaded record is known to TypeScript without you writing a single type annotation by hand. Anyone who has ever spent hours chasing a bug that came down to a URL parameter being named differently than expected will see the value immediately. Unlike the data libraries, however, Router is limited to React and Solid.
TanStack Start builds on Router and is the youngest, most ambitious piece: a full-stack framework with server-side rendering, streaming and server functions, built on Vite and running on React and Solid. This puts TanStack in direct competition with Next.js. The conceptual difference: Start thinks client-first and calls server functions explicitly, whereas Next.js thinks server-centric with React Server Components. Start has been available as a stable version 1 since March 2026; the features are complete and the interface is considered stable, but it still lacks the years of real-world use and the ecosystem of Next.js. A genuine option for a new project with an appetite for risk, but still too young for the conservative choice.
User interface
TanStack Table is the second best-known library after Query and the gold standard for complex data tables. Wherever users have to sort, filter and page through large amounts of tabular data, for example in order lists, product catalogues or reporting dashboards, Table takes over all of the logic and leaves the look to you. It supports practically all common frameworks: React, Vue, Solid, Svelte, Angular, Qwik and Lit.
TanStack Form closes the last big gap: type-safe, high-performance form management for complex input screens with many fields, validation and conditional logic. With seven framework adapters, it is one of the broadest offerings in the stack and has been production-ready since the v1 release. TanStack Virtual in turn keeps extremely long lists or tables smooth by rendering only the rows that are actually visible, which is relevant wherever thousands of records need to be scrollable on a single page.
Smaller tools and the tooling
The rest are specialist tools you only need when required: Pacer for debouncing, throttling and rate limiting (beta), Hotkeys for keyboard shortcuts, Devtools as a shared debugging panel, and CLI and Intent for tooling and AI integration. These still carry alpha labels and should not play a major role in the decision for or against TanStack.
Which library can you use in production today?
This is the question that matters for an architecture decision. TanStack assigns its own maturity levels, from alpha through beta and release candidate to stable, and these labels should be taken seriously. The following overview separates what is production-ready from what is experimental:
| Library | Purpose | Maturity | Ready for production? |
|---|---|---|---|
| Query | Loading & caching server data | stable | Yes, without restriction |
| Table | Complex data tables | stable | Yes, without restriction |
| Router | Type-safe routing | stable | Yes (React/Solid) |
| Virtual | Very long lists | stable | Yes, without restriction |
| Form | Form management | stable (since v1) | Yes |
| Start | Full-stack framework | stable (since v1) | Yes, with care, for new projects |
| DB | Reactive client store | Beta | Not yet for critical systems |
| Pacer | Rate limiting and similar | Beta | Limited |
| Store, AI, Hotkeys, CLI, Intent | various | Alpha | No, experiments only |
The rule of thumb for mid-sized companies: Query, Table, Router and Virtual are a safe bet, and Form now belongs on that list too. Start is worth a look, but with the awareness that you are building on a fresh foundation. Anything in alpha belongs in the prototype, not in production.
Why this matters for e-commerce and headless commerce
Up to this point you might get the impression that TanStack is purely a developer topic with no relevance to the business. The opposite is true as soon as you think about modern storefronts and headless architectures.
In a classic Shopware set-up, the system delivers the front end and back end in one piece. But as soon as you opt for a headless or composable architecture, meaning your own storefront that is decoupled from the commerce back end via an API, you build your front end yourself. And that is when exactly the problems TanStack was made for appear.
Picture a typical B2B customer portal. A logged-in key account customer opens their order overview: several thousand order lines, filterable by date, status and delivery address, and the basket is supposed to pull the customer’s individual tiered prices live. This is exactly where the work is split across the mature libraries. Product data, basket and availability come via an API and have to be loaded, cached and kept in sync: that is TanStack Query. The long, filterable order and quote lists are handled by TanStack Table for the logic and Virtual so that even 5,000 rows scroll smoothly. The multi-step order or configurator flow with dozens of validated fields is a job for TanStack Form. And TanStack Router provides type-safe navigation through categories, filters and search parameters in the URL.
So if your team is building its own storefront on a headless back end such as Shopware, a composable stack or a framework such as MedusaJS, TanStack is one of the most obvious building blocks for the front-end layer. It does not replace the commerce back end, but it takes work off your team’s hands that would otherwise be home-grown, error-prone and expensive to maintain. This very point, building it yourself versus using proven building blocks, often decides budget and timeline in headless projects.
The 2026 shift: built for AI agents too
One development is worth mentioning for strategic decisions. TanStack has recently started positioning itself explicitly not only for developers but also for AI agents that write code. The idea behind it is surprisingly down-to-earth: a type-safe, clearly structured library is easier to use correctly not only for people but also for an AI coding assistant. Where types are missing, the model guesses and produces code that only falls apart at runtime. Where they are present, the assistant can work its way along them and gets it right first time more often.
This becomes concrete in the newer building blocks. The CLI comes with a built-in MCP server through which an agent can talk directly to the toolkit. And ‘Intent’ ships machine-readable knowledge about a library directly with the npm package, so that an agent finds it automatically instead of relying on outdated training knowledge. For day-to-day decisions this is not yet decisive, because much of it carries alpha labels. But it shows which direction the project is thinking in, and that matters if you are betting on a technology that should still hold up in five years.
When TanStack fits, and when it does not
TanStack is not an end in itself. It is an excellent fit when your team builds its own demanding web interface, maintains its own design system and values type safety and long-term maintainability. For data-intensive applications such as dashboards, portals, headless storefronts or internal tools with large tables, it is currently one of the best foundations available.
It is a poorer fit if your team needs a standard off-the-shelf interface quickly. The headless approach means that someone actually has to build the look. A team without solid JavaScript and TypeScript depth will not get the full potential out of it, and for a simple marketing website the stack is simply oversized. If a ready-made component set gets you there in two weeks, that is often the more pragmatic route. If the TypeScript depth is missing in-house, a React agency with TanStack experience fills that gap.
One thing needs to be put on the table that is often missing from marketing overviews: supply chain security. Even a popular open-source project is not immune to attacks on the npm package ecosystem. In May 2026, during the ‘Mini Shai-Hulud’ attack wave, numerous TanStack packages were also compromised: according to analyses, around 84 malicious artefacts across roughly 42 affected packages. This is not a flaw specific to TanStack but a systemic risk of every dependency from the npm ecosystem. But that is precisely why dependency hygiene with pinned versions, audits, lockfiles and monitoring is part of every serious adoption. Anyone who uses open-source building blocks takes on this responsibility too.
Conclusion: where TanStack stands today
TanStack is not a framework that competes with React but a toolkit that adds to your framework the layers every serious web application needs. Its core is headless, type-safe, framework-independent and free of vendor lock-in, and its mature parts are so well proven that the biggest tech companies build on them.
The honest assessment for an architecture decision: Query, Table, Router and Virtual are production-ready today and an excellent choice, especially for data-intensive and headless commerce front ends. Form has caught up. Start is the exciting bet on the future, but still young. The rest is workshop, not foundation.
Remember the introduction? The chances are high that a piece of TanStack is already in your code. So the real question is not whether the stack fits your architecture, but which of the mature libraries you will deliberately use next instead of laboriously rebuilding them yourself. The most sensible starting point is the narrowest one: start with TanStack Query in a real project. It solves a concrete problem every team knows, is low-risk and at the same time conveys the way of thinking on which the entire stack is based. From there you expand piece by piece, or not, depending on what your project really needs. This freedom of choice is exactly the point.
If your team is planning a headless storefront or a data-intensive web application and is unsure which building blocks suit your stack, a sober architecture check before the first line of code is written pays off. You can see how we use TanStack in production projects on our TanStack agency page.