TL;DR
TanStack DB is the safest 2026 pick if you want incremental, reactive client-side queries that compose with TanStack Query and run anywhere — minimal server-side commitment. Zero (from Rocicorp, the Replicache successor) is the strongest end-to-end story when you can adopt their server protocol and a Postgres backend. LiveStore is the right call for event-sourced, log-driven apps where you want SQLite-on-the-client with a deterministic mutation log. All three are part of the 2026 wave of "the client is no longer a dumb cache" — they treat your UI's data layer as a real reactive query engine, not a chain of useEffect hooks. Pick based on how much of your stack you're willing to rebuild around the sync engine.
Quick Verdict
| TanStack DB | Zero | LiveStore | |
|---|---|---|---|
| Maker | TanStack | Rocicorp | Overtone (Schickling et al.) |
| Local store | In-memory + indexes | SQLite (Wasm/native) | SQLite (Wasm/native) |
| Query language | JS/TS query builder | ZQL (typed query DSL) | SQL + reactive views |
| Conflict resolution | Optimistic + server reconciliation | Server-authoritative + rebases | Event log (CRDT-like) |
| Server requirement | Any HTTP backend | Zero-cache server (Rocicorp) | Sync server (open source) |
| Backend coupling | Loose | Tight (Postgres + zero-cache) | Tight (event log) |
| Adoption stage | RC / 1.0 in 2026 | GA | Beta / 1.0 |
Key Takeaways
- The new bar is incremental queries. All three deliver sub-millisecond reactive query updates by maintaining indexes/materialized views in the client, not by re-running queries against the network.
- Server commitment is the deciding factor. TanStack DB asks for the least; Zero asks for the most. Adopt Zero only when you're willing to put
zero-cachein your stack as a real component. - CRDT vs server-authoritative is a real philosophical split. LiveStore leans CRDT-like (event log, deterministic replay). Zero is server-authoritative (the server resolves; clients rebase). TanStack DB mostly delegates to your server's existing semantics.
- TanStack Query is not going away. TanStack DB layers on top of TanStack Query in many setups; if you already use TanStack Query, the migration cost is the lowest of the three.
What Each One Actually Is
TanStack DB
Technically a "reactive client store with incremental views". You define collections, write JS-style queries with joins/where/order, and the engine maintains those query results incrementally as mutations come in. It does not prescribe how data gets to the server — you wire it up to your existing API, GraphQL endpoint, or tRPC v11 procedures.
import { createCollection, createQuery } from "@tanstack/db";
const todos = createCollection<Todo>("todos", {
queryFn: () => fetch("/api/todos").then(r => r.json()),
});
const openTodos = createQuery({
from: todos,
where: (t) => !t.completed,
orderBy: (t) => t.createdAt,
});
// In a React component, openTodos.subscribe() updates incrementally
The selling point is "I want my UI to feel local-first, but I don't want to throw out my REST API." It pairs naturally with TanStack Query for transport and cache invalidation.
Zero
Rocicorp's successor to Replicache. The bet is bigger: Zero ships its own query language (ZQL), its own server (zero-cache), and its own protocol. In return you get true sync semantics — a permission model that runs on the server, end-to-end query subscriptions, and rebase-on-conflict handling.
import { Zero } from "@rocicorp/zero";
const z = new Zero({
userID: "user-42",
server: "https://zero.example.com",
schema, // generated from Postgres
});
const issues = z.query.issue
.where("assigneeId", "=", "user-42")
.orderBy("createdAt", "desc")
.limit(50);
// `issues` is reactive — subscribe in React via useQuery(issues)
Zero is the most complete answer here, but you commit to Postgres, the zero-cache server, and Rocicorp's hosted or self-hosted infrastructure.
LiveStore
Built around an event-sourced model: every mutation is an event appended to a log; the client materializes views (SQLite tables) by replaying the log; the server is itself a log replicator. This makes time-travel, undo, and offline merging cleaner than a traditional CRUD model.
import { makeStore, defineEvents, sql } from "@livestore/livestore";
const events = defineEvents({
todoCreated: { schema: { id: "string", text: "string" } },
todoCompleted: { schema: { id: "string" } },
});
const store = await makeStore({
events,
materializers: {
todoCreated: ({ id, text }) =>
sql`INSERT INTO todos (id, text, completed) VALUES (${id}, ${text}, 0)`,
todoCompleted: ({ id }) =>
sql`UPDATE todos SET completed = 1 WHERE id = ${id}`,
},
});
await store.commit(events.todoCreated({ id: "t1", text: "buy milk" }));
const open = await store.query(sql`SELECT * FROM todos WHERE completed = 0`);
You write SQL (or use the typed builder) against a real SQLite database that lives in the user's browser via sqlite-wasm. The mutation log is the source of truth; the table is a view.
Decision Map
| If you... | Pick |
|---|---|
| Already use TanStack Query and want incremental views | TanStack DB |
| Want the most complete sync story and can adopt zero-cache | Zero |
| Need event-sourced semantics or time-travel | LiveStore |
| Have an existing REST API you can't rewrite | TanStack DB |
| Are starting greenfield with Postgres | Zero |
| Need offline-first with deterministic merge | LiveStore |
| Need a hosted, "just works" sync provider today | Convex / InstantDB / ElectricSQL |
Server Requirements: The Real Cost
This is where most architecture decisions land:
| TanStack DB | Zero | LiveStore | |
|---|---|---|---|
| Add a new server? | No (use yours) | Yes (zero-cache) | Yes (sync server) |
| Backend protocol | Whatever you have | Zero-specific | LiveStore-specific |
| Permission layer | In your existing API | In zero-cache config | In materializer / replication |
| Postgres required | No | Effectively yes | No |
Zero's zero-cache is the most opinionated component. You run it next to your Postgres, it tails replication, and it serves filtered query subscriptions to clients. This is power and operational complexity.
Conflict Resolution Models
- TanStack DB: optimistic mutations + server reconciliation. If the server rejects, your client rolls back. Simple, but means the server is still the source of truth for conflicts.
- Zero: server-authoritative with client-side rebase. Clients optimistically apply, the server resolves, the client rebases on top of the canonical history. Closer to git semantics.
- LiveStore: event-sourced. Conflicts are resolved by event ordering rules and materializer determinism. The mental model is closer to CRDTs without committing to a CRDT library.
For broader local-first context (and database engines that pair with these), see PGlite vs ElectricSQL vs Triplit.
Who Should Pick What
- Existing React app with TanStack Query: TanStack DB. The migration is incremental and your server stack is untouched.
- Greenfield collaborative app, Postgres-backed: Zero. The protocol/server cost is real but the result is the slickest sync story available in 2026.
- Event-sourced app or one that needs replay/audit semantics: LiveStore. Don't try to retrofit event sourcing onto TanStack DB; you'll fight the model.
- Production-critical data-sync need today: a hosted option (Convex, InstantDB) is still the safer pick for non-experimental teams in early 2026.
Verdict
TanStack DB is the lowest-risk 2026 entry into incremental client-side queries — no new server, no new protocol. Zero is the most ambitious and the most complete; treat it as a multi-quarter platform commitment. LiveStore is a niche-but-deep choice for event-sourced apps. The category is moving fast: re-evaluate before any greenfield commitment because GA timelines and hosted offerings continue to shift through 2026.