惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

人人都是产品经理
人人都是产品经理
博客园_首页
博客园 - 三生石上(FineUI控件)
V
Visual Studio Blog
Hugging Face - Blog
Hugging Face - Blog
美团技术团队
小众软件
小众软件
T
Tailwind CSS Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
月光博客
月光博客
有赞技术团队
有赞技术团队
WordPress大学
WordPress大学
博客园 - 【当耐特】
Apple Machine Learning Research
Apple Machine Learning Research
罗磊的独立博客
V
V2EX
酷 壳 – CoolShell
酷 壳 – CoolShell
IT之家
IT之家
量子位
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Recent Announcements
Recent Announcements
M
MIT News - Artificial intelligence
阮一峰的网络日志
阮一峰的网络日志
The GitHub Blog
The GitHub Blog

TanStack Blog

TanStack + Vercel Partnership | TanStack Blog TanStack AI Enters the RC Phase | TanStack Blog Inside a TanStack Router Navigation | TanStack Blog Form v2 is here: All you need to know about the alpha | TanStack Blog Announcing TanStack Table V9 | TanStack Blog TanStack Has a New Look | TanStack Blog Introducing TanStack Markdown and TanStack Highlight | TanStack Blog We Removed React Server Components from TanStack.com | TanStack Blog We Stopped Using RSC on TanStack.com | TanStack Blog Inside TanStack Table V9 Reactivity | TanStack Blog Run Any Coding Agent in a Sandbox, With One chat() Call | TanStack Blog TanStack Start and TanStack AI Win 2026 Open Source Awards | TanStack Blog How an Underrated Refactor Saved 90% Memory Usage | TanStack Blog TypeScript Performance in TanStack Table V9 | TanStack Blog TanStack AI Beta: The Switzerland of AI Tooling Grows Up | TanStack Blog TanStack Table V9: Taking Form | TanStack Blog TanStack AI: Your MCP, your way | TanStack Blog TanStack Start Adds First-Class Rsbuild Support | TanStack Blog Introducing Experimental Workflows and Orchestrators in TanStack AI | TanStack Blog Chat UIs Are Lists Until They Aren't | TanStack Blog Structured Output That Remembers Across Turns | TanStack Blog TanStack Virtual just got a lot faster, and finally handles iOS | TanStack Blog TanStack AI now fully speaks AG-UI | TanStack Blog Stop Waiting on JSON: Stream Structured Output with One Schema | TanStack Blog Hardening TanStack After the npm Compromise | TanStack Blog Postmortem: TanStack npm supply-chain compromise | TanStack Blog Who Owns the Tree? RSC as a Protocol, Not an Architecture | TanStack Blog TanStack AI Just Learned to Compose Music | TanStack Blog Your AI Tool Calls Should Fail at Compile Time, Not in Production | TanStack Blog One Flag, Every Chunk: Debug Logging Lands in TanStack AI | TanStack Blog
Stop Re-Rendering. TanStack DB, the Embedded Client Datab...
co-authored by Kyle Mathews and Sam Willis · 2025-07-30 · via TanStack Blog

by Kyle Mathews and Sam Willis on Jul 30, 2025.

Stop rerendering

Your React dashboard shouldn't grind to a halt just because one TODO turns from ☐ to ☑. Yet every optimistic update still kicks off a cascade of re-renders, filters, useMemos and spinner flashes.

If you’ve ever muttered “why is this still so hard in 2025?”, same.

TanStack DB is our answer: a client-side database layer powered by differential dataflow that plugs straight into your existing useQuery calls.

It recomputes only what changed, 0.7 ms to update one row in a sorted 100k collection on an M1 Pro (CodeSandbox)

One early-alpha adopter, building a Linear-like application, swapped out a pile of MobX code for TanStack DB and told us with relief, “everything is now completely instantaneous when clicking around the app, even w/ 1000s of tasks loaded.”

Why it matters

Today most teams face an ugly fork in the road:

Option A. View-specific APIs (fast render, slow network, endless endpoint sprawl) or

Option B. Load-everything-and-filter (simple backend, sluggish client).

Differential dataflow unlocks Option C: load normalized collections once, let TanStack DB stream millisecond-level incremental joins in the browser. No rewrites, no spinners, no jitter.

Live queries, effortless optimistic writes, and a radically simpler architecture, all incrementally adoptable.

Try out the TanStack DB Starter

TanStack DB keeps a normalized collection store in memory, then uses differential dataflow to update query results incrementally. Think of it like Materialize-style streaming SQL, except embedded in the browser and hooked straight into React Query’s cache.

  • Collections wrap your existing useQuery calls (REST, tRPC, GraphQL, WebSocket, doesn’t matter). Do you sync data some other way? Build a custom collection.
  • Transactions let you mutate those collections optimistically; failures roll back automatically.
  • Live queries declare what data you need; TanStack DB streams only the rows that change, in < 1 ms.

Put differently: TanStack Query still owns “how do I fetch?”; TanStack DB owns “how do I keep everything coherent and lightning-fast once it’s here?”

And because it’s just another layer on top of queryClient, you can adopt it one collection at a time.

Imagine we already have a backend with a REST API that exposes the /api/todos endpoint to fetch a list of todos and mutate them.

Before: TanStack Query

After: TanStack DB

TanStack Query is incredibly popular with 12m (and counting) downloads per week. So why make something new like TanStack DB?

Query solves the hardest problems of server state management: intelligent caching, background synchronization, request deduplication, optimistic updates, and seamless error handling.

It's become the de facto standard because it eliminates the boilerplate and complexity of managing async data fetching while providing an excellent developer experience with features like automatic background refetching, stale-while-revalidate patterns, and powerful DevTools.

But Query treats data as isolated cache entries. Each query result is independent, there's no concept of relationships, live queries across multiple data sources, or reactive updates when one piece of data affects another. You can't easily ask "show me all todos where the project status is active" and watch the list update automatically when a project flips status.

TanStack DB fills this gap. While Query excels at fetching and caching server state, DB provides the missing reactive, relational layer on top. You get the best of both worlds: Query's robust server state management plus TanStack DB’s embedded client database that can join, filter, and reactively update across your entire data graph.

But it doesn’t just improve your current setup. It enables a new radically simplified architecture.

Let's revisit the three options:

Option A. View-Specific APIs: Create view-specific API endpoints that return exactly what each component needs. Clean, fast, zero client-side processing. But now you're drowning in brittle API routes, dealing with network waterfalls when components need related data, and creating tight coupling between your frontend views and backend schemas.

Option B. Load-everything-and-filter: Load broader datasets and filter/process them client-side. Fewer API calls, more flexible frontend. But you slam into the performance wall: todos.filter(), users.find(), posts.map(), useMemo() everywhere, with cascading re-renders destroying your UX.

Most teams pick Option A to avoid performance problems. You're trading client-side complexity for API proliferation and network dependency.

TanStack DB enables Option C – Normalized Collections + Incremental Joins: Load normalized collections through fewer API calls, then perform lightning-fast incremental joins in the client. You get the network efficiency of broad data loading with sub-millisecond query performance that makes Option A unnecessary.

Instead of this:

You can do this:

Now, clicking between projects, users, or views requires zero API calls. All the data is already loaded. New features like "show user workload across all projects" work instantly without touching your backend.

Your API becomes simpler. Your network calls drop dramatically. Your frontend gets faster as your dataset grows.

Your app would be dramatically faster if you just loaded 20MB of normalized data upfront instead of making hundreds of small API calls.

Companies like Linear, Figma, and Slack load massive datasets into the client and achieve incredible performance through heavy investment in custom indexing, differential updates, and optimized rendering. These solutions are too complex and expensive for most teams to build.

TanStack DB brings this capability to everyone through differential dataflow, a technique that only recomputes the parts of queries that actually changed. Instead of choosing between "many fast API calls with network waterfalls" or "few API calls with slow client processing," you get the best of both options: fewer network round-trips AND sub-millisecond client-side queries, even with large datasets.

This isn't just about sync engines like Electric (though they make this pattern incredibly powerful). It's about enabling a fundamentally different data loading strategy that works with any backend: REST, GraphQL, or real-time sync.

While TanStack DB works great with REST and GraphQL, it really shines when paired with sync engines. Here's why sync engines are such a powerful complement:

Easy real-time: If you need real-time updates, you know how painful it can be to set up WebSockets, handle reconnections, and wire up event handlers. Many new sync engines are native to your actual data store (e.g., Postgres) so you can simply write to the database directly and know the update will get streamed out to all subscribers in real-time. No more manual WebSocket plumbing.

Side-effects are pushed automatically: When you do a backend mutation, there are often cascading updates across multiple tables. Update a todo's status? That might change the project's completion percentage, update team metrics, or trigger workflow automations. With TanStack Query alone, you need manual bookkeeping to track all these potential side-effects and reload the right data. Sync engines eliminate this complexity, any backend change that happens during a mutation is automatically pushed to all clients - without any extra work.

Load far more data efficiently: It's far cheaper to update data in the client when using sync engines. Instead of re-loading entire collections after each change, sync engines send only the actual changed items. This makes it practical to load far more data upfront, enabling the "load everything once" pattern that makes apps like Linear feel so fast.

TanStack DB was designed from the ground up to support sync engines. When you define a collection, you're provided with an API for writing synced transactions from the backend into your local collections. Try out collection implementations for Electric, Trailblaze, and (soon) Firebase!

DB gives you a common interface for your components to query data, which means you can easily switch between data loading strategies as needed without changing client code. Start with REST, switch to a sync engine later as needed, your components don't need to know the difference.

We're building TanStack DB to address the client-side data bottlenecks that every team eventually hits. Here's what we're aiming for:

  • True backend flexibility: Work with any data source through pluggable collection creators. Whether you're using REST APIs, GraphQL, Electric, Firebase, or building something custom, TanStack DB adapts to your stack. Start with what you have, upgrade if needed, mix different approaches in the same app.
  • Incremental adoption that actually works: Start with one collection, add more as you build new features. No big-bang migrations or development pauses.
  • Query performance at scale: Sub-millisecond queries across large datasets through differential dataflow, even when your app has thousands of items.
  • Optimistic updates that don't break: Reliable rollback behavior when network requests fail, without complex custom state management.
  • Type and runtime safety throughout: Full TypeScript inference from your schema to your components, catching data mismatches at compile and runtime.

We're excited about giving teams a fundamentally better way to handle client-side data, while preserving the freedom to choose whatever backend works best.

TanStack DB 0.1 (first beta) is available now. We're specifically looking for teams who:

  • Already use TanStack Query and hit performance/code complexity walls with complex state
  • Build collaborative features but struggle with slow optimistic updates
  • Have 1000+ item datasets causing rendering performance issues
  • Want real-time functionality without rewriting their entire data layer
  • First 20 teams get migration office hours

If your team spends more time optimizing React re-renders than building features, or if your collaborative features feel sluggish compared to Linear and Figma, TanStack DB is designed for exactly your situation.

Get started today:

No more stutters. No more jank. Stop re-rendering, start shipping!