TanStack Query generated 60 release events in 30 days, more than one for every 12 hours. That number is real, but the interesting story is not that its users endured 60 meaningful product changes. The release feed exposes how a mature, multi-framework library ships a graph of coordinated packages, and why raw release counts can exaggerate volatility while still revealing serious maintenance work.

Server state is the product boundary

The official repository defines TanStack Query as an async state management library for fetching, caching, synchronizing, and updating server state. That scope matters. It is not an HTTP client, and it does not care whether data arrives through REST, GraphQL, a promise, or another transport. It manages what happens around the request: caching, background refetches, pagination, infinite queries, mutations, cancellation, prefetching, and the transition between pending, error, and successful states.

The official React overview makes the distinction sharper. Server state is remote, shared, asynchronous, and liable to change without the client initiating that change. A local state container can hold a copy, but it does not automatically solve staleness, duplicate requests, garbage collection, retries, or background updates. Query packages turn those concerns into explicit policies rather than scattering them across components.

TanStack’s main site describes its libraries as headless, type-safe, and composable. It also says each library starts with a provider-agnostic core. The Query repository reflects that model through React, Vue, Solid, Svelte, and experimental Angular packages around @tanstack/query-core. This is the central architectural bet: one server-state model, adapted to several reactive runtimes instead of rewritten independently for each framework.

The licensing signal is equally clear. ToolVitals classifies TanStack Query as OSI-approved open source under the MIT license. No hosted pricing is tracked. That means the library is not tied to a paid Query service, but it does not mean every backend, monitoring product, or integration used beside it is free.

Sixty release events do not mean sixty product leaps

ToolVitals gives TanStack Query a 230.8 hot score, a 100 health score, a 100 shipping score, and a 100 overall ToolVitals score. Data confidence is 100. The repository has 49,980 GitHub stars, 30 GitHub releases in 90 days, and 60 release events in the latest 30-day window.

Those figures establish three things. The project is highly visible, its public maintenance signals are current, and its release machinery is busy. They do not establish that the API changed 60 times or that an application needed 60 dependency upgrades.

The July 22 release is the cleanest example. One release bundle upgraded Solid to version 2 beta 21 and adjusted prerelease tag assignment. That bundle produced a coordinated @tanstack/solid-query@6.0.0-beta.6 release plus matching devtools and persistence-client releases. In the supplied event stream, the bundle and its three package tags appear as four events tied to the same underlying change.

That is not fake activity. Each package is an independently consumable artifact with its own version, dependency edges, and users. Publishing all affected packages is correct. But a release-event counter measures artifacts and release records, not independent engineering decisions.

The 30 releases in 90 days and 60 events in 30 days also use different ToolVitals signals and windows. Readers should not force them into a single hand-calculated cadence. The safe conclusion is narrower: TanStack Query has an unusually dense package-level release stream, and recent events show that coordinated packages can multiply one change into several records.

This distinction matters for engineering leads. A busy feed can imply quick fixes and current framework support, but it can also create Dependabot noise, lockfile churn, and extra triage. Before adopting Query, inspect the changelog for the adapter you use, not the repository-wide release count alone. Measure how often stable packages contain behavior changes versus dependency-only bumps.

The current release direction is framework adaptation

The most visible recent work is not a rewrite of Query’s core. It is Solid 2.0 support. TanStack announced beta support for Solid 2.0 across Router, Start, and Query in April 2026, with @tanstack/solid-query on a version 6 beta line. The announcement says the TanStack APIs are mostly unchanged and attributes the main breaking changes to Solid 2.0 itself.

The July 22 6.0.0-beta.6 releases continued that work by upgrading to Solid 2 beta 21. This is a useful signal for Solid teams: TanStack is tracking an upstream beta rather than waiting for the framework to stabilize. It is also a warning. Beta alignment means consumers are participating in two moving release trains, Solid and its Query adapter.

TanStack’s announcement explicitly calls the support early and asks users to report rough edges. It says the team plans to track Solid from beta through release candidate to stable. That is a concrete roadmap statement, but not a stable-release date or compatibility guarantee. A production team should pin versions, test SSR and async behavior, and treat the beta package separately from the mature version 5 packages used elsewhere.

Another July 21 patch shows a different kind of maintenance. @tanstack/eslint-plugin-query@5.101.4 relaxed its exhaustive-deps rule so function call targets are not required in query keys, while values referenced inside nested callbacks are still checked. This is small, but it touches the feedback loop developers feel every day. Mature libraries are maintained partly through this kind of friction removal, not only through headline features.

TanStack’s website changes reveal an engineering preference

Two July 24 posts concern tanstack.com rather than TanStack Query directly, so they should not be counted as Query releases. They still provide useful context about how the maintainers make technical tradeoffs.

TanStack first used React Server Components to keep a heavy Markdown and syntax-highlighting pipeline out of the browser. Its post reports that one documentation page had transferred about 1.1 MiB of script, with roughly 358 KiB tied to highlighting. On a measured blog page, the RSC move raised Lighthouse from 52 to 74, cut Total Blocking Time from 1,200 ms to 260 ms, and reduced transfer size from 1,101 KiB to 785 KiB.

The team then removed RSC from the site after replacing the expensive content stack with narrower libraries. The companion announcement says the TanStack Markdown parser is currently 4.9 KB gzipped, while the HTML renderer and framework adapters are about 6.7 KB gzipped, with zero runtime dependencies. Those are tanstack.com and Markdown measurements, not TanStack Query bundle claims.

The broader principle is relevant to Query adoption: solve the actual state problem, but keep questioning whether the surrounding abstraction still earns its complexity. Query can remove a large amount of hand-built cache coordination. It can also become habitual infrastructure in screens that only need a simple request. The maintainers’ own website story argues for measuring the expensive part and deleting architecture when a smaller solution becomes sufficient.

What ToolVitals cannot infer

A perfect ToolVitals score does not prove code quality. ToolVitals can observe public activity, releases, stars, website health, SSL, and other external signals. It cannot see whether Query fits a particular application, whether a release introduced a subtle cache regression, how satisfied users are, or how quickly a difficult issue gets resolved.

The payload has no 30-day commit count and no active-contributor count for this tool. Those fields are null, not zero. We therefore cannot infer contributor breadth, review capacity, maintainer concentration, or how much of the release stream was automated. The 49,980 stars are cumulative attention, not active installations or retained production users.

ToolVitals also does not provide npm downloads, bundle cost by adapter, issue-response percentiles, security audit results, revenue, or migration failure rates here. The official sources explain intended behavior and current work, but they do not substitute for a team-specific benchmark.

A skeptical buyer should run a narrow pilot. Pick one data-heavy route with pagination, mutations, and an invalidation requirement. Define query keys, staleTime, retry behavior, SSR hydration, and error boundaries explicitly. Then measure request duplication, cache correctness, bundle impact, test complexity, and upgrade noise. If the pilot only replaces a small fetch call with more concepts, stop. If it deletes bespoke synchronization code and makes stale-data policy visible, the library is doing its job.

For TanStack’s maintainers, the same release density suggests a documentation opportunity. A repository-wide weekly digest that groups package tags by underlying change would preserve precise package releases while making the human signal easier to read. Separating stable core behavior, adapter changes, beta-framework tracking, and dependency-only bumps would help teams interpret the impressive activity without mistaking artifact count for product churn.

Comparisons need category context

ToolVitals lists React Email and Next.js as related tools, not direct TanStack Query substitutes. React Email has a 229.3 hot score, 19,485 stars, and 32 release events in 30 days. Next.js has a 224.2 hot score, 141,102 stars, and 33 release events. All three have a 100 shipping score.

TanStack Query therefore has fewer stars than Next.js but a higher hot score and nearly twice its 30-day release events. It also has more than twice React Email’s stars and 28 more release events. The comparison shows why stars, heat, and shipping must remain separate dimensions. Popularity is cumulative. Release activity is recent. Neither says the tools solve the same problem or carry the same package topology.

Recommendation

If your application has shared remote data, background refreshes, pagination, mutations, or cache invalidation spread across several components, evaluate TanStack Query now. Its provider-agnostic core, mature version 5 line, MIT license, 49,980-star repository, and current adapter work make it a strong default candidate.

Do not adopt it because ToolVitals counted 60 release events. Adopt it if a pilot proves that explicit server-state policies remove more custom coordination than the library adds. React and Vue teams should evaluate the stable adapter they will actually ship. Solid 2.0 teams should test the version 6 beta behind pinned dependencies and CI coverage. The activity signal is excellent. The package graph is busy. Your decision should rest on whether Query makes server state simpler in your codebase, not whether its release feed moves fastest.

Sources