TanStack DB: a reactive client store for your API, still in beta

What TanStack DB is for

The README states the project's purpose in one line: it is "the reactive client store for your API." The problem it targets is the shape of a typical data-heavy client app. Loading data through many endpoints produces network waterfalls, and each screen tends to keep its own copy of the same entity. TanStack DB asks you to load that data into normalized collections instead, so one entity lives in one place and many views read from it. The README lists three intended outcomes: avoiding endpoint sprawl and network waterfalls, sub-millisecond live queries with real-time reactivity, and optimistic writes that take the network off the interaction path. The audience is front-end engineers building apps where interaction latency matters and the backend is an API the team already has. It is not a database server. Nothing in the README describes a process you deploy, a wire protocol, or a storage engine of its own. It is a client-side library, and the docs live at tanstack.com/db.

Collections, live queries and optimistic writes

The architecture visible in the README is three layers. Collections hold normalized data loaded from your API. Live queries read from those collections and update when the underlying data changes. Optimistic writes let an interaction update the local collections immediately, before the server confirms. That ordering is what makes the interaction feel instantaneous: the client applies the change to its own collections, the query layer re-runs against them, and the network round trip happens behind the user's back. The repository layout shows how the pieces are packaged. The packages/ directory holds the core library plus adapter packages, and the release list names several of them: @tanstack/vue-db, @tanstack/trailbase-db-collection, and @tanstack/tauri-db-sqlite-persistence. Those names tell you the design is adapter-based. A collection can come from a query library, from a sync service, or from a local store, and persistence is a separate concern you opt into. The root package.json also reveals an internal package, @tanstack/db-ivm, which the typecheck script references. The README does not explain what that package does, so treat the query engine's internals as undocumented from the outside.

Installing TanStack DB and running a first collection

The README does not include install commands. It links to the docs at tanstack.com/db, and the npm badge points at the @tanstack/db package, so that is the package name to look up. The repository is a pnpm workspace managed with [email protected], and the root scripts show the build and test flow for contributors rather than consumers.

If you are working on the library itself, the root package.json defines the workspace commands. Installing dependencies and building every package under packages/ looks like this:

pnpm install
pnpm build

The build script is defined as pnpm --filter "./packages/**" build, so it runs the build task in every package under packages/. A contributor running the test suite uses the test script, which filters the same way:

pnpm test

There is also a docs link check, which is useful if you change anything under docs/:

pnpm test:docs

That script runs node scripts/verify-links.ts. For consumers, the README points at the docs site and at the examples/ directory, which contains framework-specific examples for React, Solid, Angular, Electron and React Native. Those examples are the closest thing to a first real use that the repository ships.

Where TanStack DB is the wrong tool

The first line of the README is a beta notice, and it links to a release post about version 0.1 titled "the embedded client database for TanStack Query." Version numbers in the release list are still in the 0.x range: @tanstack/[email protected], @tanstack/[email protected], @tanstack/[email protected]. A 0.x version line means the API can change between minors, and the changesets directory at the repository root confirms releases are cut through changesets rather than on a fixed schedule. If your team cannot absorb breaking changes in a data layer, this is the wrong moment to adopt it.

The second boundary is scope. TanStack DB is a client store. It does not replace your server database, your API, or your authorization layer. If your problem is querying data on the server, this project has nothing to say about it. It also assumes you can load data into collections in the first place, which means your API has to return entities you can normalize. An API that only exposes pre-computed, view-shaped responses gives the collection layer little to work with. Finally, the README documents no rollback behaviour for optimistic writes. It states that writes are optimistic and that the network leaves the interaction path, but it does not describe what happens when the server rejects the write. That is a real gap to close before you put optimistic writes in front of anything a user pays for.

TanStack DB compared with TanStack Query and Zustand

The most common comparison is with TanStack Query, and the two solve different halves of the problem. TanStack Query is an async state and caching layer: you fetch, it caches, you invalidate. It does not normalize entities across queries, and it does not give you a query language over the cached data. TanStack DB is built around collections and live queries, so it answers questions like "which todos belong to this list, sorted by due date" from local data rather than from a fresh request. The release post title calls TanStack DB "the embedded client database for TanStack Query," which suggests the intended pattern is to use them together: Query fetches, DB stores and queries. They are not substitutes.

Against Zustand, the difference is what the store knows. Zustand is a general state container; you decide what goes in it and how it is updated. TanStack DB has opinions about data shape (collections), about reads (live queries) and about writes (optimistic mutations). That is more machinery, and it only pays off when your state is mostly server data. For UI state like a modal flag or a theme, a general store is the simpler choice. Against IndexedDB, the difference is level. IndexedDB is a browser storage API; the related searches about TanStack DB and IndexedDB, and the tauri-db-sqlite-persistence package, suggest persistence is handled by adapters on top of the core rather than by the core itself.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-23. The most recent releases listed are from 2026-09-14, including @tanstack/[email protected] and @tanstack/[email protected]. The project is licensed under MIT, which permits commercial use and modification provided the licence and copyright notice are preserved. That is a permissive licence, and no part of the README suggests additional terms. For legal questions about how MIT applies to your distribution, ask a lawyer rather than an article.

The upgrade cost is the more interesting number. The repository uses changesets, so every release carries a version bump and a changelog entry, and the changeset:version script also runs scripts/update-example-deps.ts and reinstalls with --no-frozen-lockfile. That means the examples are versioned alongside the packages and are expected to track them. For a consumer, the practical consequence is that examples in the repository are a reasonable reference for the version they were published with, and older blog posts may not match. The docs are generated by scripts/generate-docs.ts and link-checked by scripts/verify-links.ts, so documentation drift is at least being watched. None of that removes the 0.x risk. Budget for reading changelogs on every minor bump.

Editorial conclusion

TanStack DB fits teams already inside the TanStack ecosystem who want normalized collections and live queries in front of an existing HTTP API, and who can absorb beta churn. Teams that need a stable, versioned data layer, or a server-side database, should not adopt it yet. Before committing, check the release post linked in the README for the beta terms, and confirm which collection adapters and persistence packages exist for your framework and storage target.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. TanStack/db on GitHub