Best practices for large-scale offline-first app with useLiveQuery + state management ?

[jonathan-pyt]

Stack:

• Expo SDK 53 + React Native
• Drizzle ORM + Expo SQLite
• Legend State for reactive state management
• Offline-first architecture with sync queue

Context:

SQLite is our single source of truth. We use useLiveQuery with some additions like debounce and enabled options to make it more manageable.

One issue we've encountered with Expo Router: when navigating between stacks, components aren't unmounted — they stay in memory. This means live queries keep running in the background across different stacks, listening for changes and re-executing even when the screen isn't visible. We've had to manually handle this with the enabled option based on focus state, which adds boilerplate.

The Problems:

As the app scales, we're hitting friction points:

1. Query re-execution: Live queries re-run on table changes, even when actual data hasn't changed.
2. Zombie queries: With Expo Router's stack navigation, queries from previous screens keep executing in the background unless manually disabled.
3. State hydration: We use Legend State for derived/computed state, but keeping it in sync with live queries creates dual state management. We'd like to hydrate observables once and invalidate manually rather than re-querying constantly.
4. No query deduplication: Same query used in multiple components = multiple DB listeners and executions.
5. Cache control: No fine-grained invalidation strategy — it's either "live" (always re-run) or nothing.

Considering React Query:

We're thinking about migrating to React Query for:

• Query caching & deduplication
• Built-in focus/visibility handling
• Manual invalidation with queryClient.invalidateQueries()
• Stale-while-revalidate patterns

But we'd lose the automatic "live" reactivity that useLiveQuery provides.

Questions:

1. How do you handle this in large-scale offline-first apps with Drizzle?
2. Is there a pattern for combining live queries with a caching layer?
3. Has anyone migrated from useLiveQuery to React Query?
4. Any other approaches we should consider?

Thanks!

[michel-lamarliere]

Hey! I was wondering if you migrated to Tanstack Query. If so, how's the performance?

[jonathan-pyt]

Hey @michel-lamarliere

No, we're still on a custom useLiveQuery setup on top of addDatabaseChangeListener. With a few additions (an enabled flag, AbortController, and a small debounce on change events related to #2953
it's stayed usable with low lag so far, so we haven't pulled the trigger on the migration.

Still keeping it in the back of my mind though

[mosioc]

Hi @jonathan-pyt :D

Chiming in here because we're running a very similar stack (Expo + Drizzle + SQLite, offline-first; I'm from Iran. The government here cuts the internet, and we have critical issues connecting to the network. VPN prices are skyrocketing. offline-first is mandatory) and have hit the exact same pain points.

Wanted to share what's worked for us since it sounds like you're at the same crossroads and let me try my best to give it the response it deserves.

• On the zombie query problem with Expo Router: We took a slightly different approach than the enabled flag tied to focus state. Instead, we wrapped useLiveQuery in a custom hook that accepts a React Navigation useIsFocused()-style boolean, and internally we don't just disable the query, we conditionally skip registering the listener entirely when the screen isn't focused, and abort any in-flight query (like you mentioned with AbortController). The result is that unfocused screens generate zero listener overhead, rather than running and ignoring results. The boilerplate is still there per-screen, but it's a one-liner: const { data } = useManagedLiveQuery(query, { enabled: isFocused }).

• On query deduplication and re-execution: This is the big one we solved by implementing a thin cache layer between the live queries and the components, rather than going full React Query. We built a QueryCache class that:

  • Maintains a Map<string, { data, listeners, unsubscribe }> keyed by a normalized query hash (SQL string + params).
  • When a component calls useCachedLiveQuery, it checks if that hash already exists. If yes, it just registers the component as a new listener and returns the cached data. Only the first caller sets up the actual live query listener. When the underlying table changes and the listener re-executes the query, we shallow-diff the result against the cached data. If nothing actually changed for that query, we skip notifying subscribers. If it did change, we update the cache entry and notify all subscribed components.
  • Deduplication happens naturally because identical queries share the same cache entry and listener. One SELECT * FROM items WHERE groupId = ? across 15 components = one listener, one execution per table change.

This gives us the live reactivity of useLiveQuery without the overhead of duplicate listeners scattered across the component tree. The cache lives in a React context at the root, so it persists across navigation stacks without re-mounting.

• On state hydration and dual state management: We also use Legend State (love it) and ran into the "two sources of truth" tension. The pattern that clicked for us: we treat the live query cache as the source for persisted data, and Legend observables for derived/transient UI state. For example, if we need a computed value like itemsByCategory, we don't re-query SQLite. Instead, we have a single live query for items, and a Legend computed that derives itemsByCategory and only recalculates when the items observable updates. The live query feeds the raw data into Legend once, and Legend handles the rest reactively. No duplicate queries for different slices of the same data.

• On migration to React Query: We seriously considered it for the exact reasons you listed. What stopped us was the realization that React Query's model is really built around client-server synchronization; stale-while-revalidate, background refetches, all optimized for data that lives on a remote server. With a local SQLite DB that is already the source of truth and gives us native change listeners, it felt like we'd be fighting the fucking paradigm (sorry) to get the same live reactivity we already have. The caching and deduplication parts of React Query are tempting, but we replicated those with the custom cache layer (maybe ~200 lines) while keeping the tight integration with Drizzle's change listeners.

What I'd recommend trying before a full migration:

1. Centralize your live queries into a cache layer with listener deduplication and result diffing. It's less code than it sounds and pays off immediately, both in performance and mental model.
2. Separate what's in the DB (live query to cache) from what's on screen (Legend deriveds from that cache). This removes the dual-state management friction.
3. For the zombie queries, skip listener registration entirely on blur rather than just disabling; so unfocused screens are truly silent, not just ignoring results.

Happy to share a gist of our QueryCache implementation if it'd be helpful.

(+ Sorry for bad english, hope it makes sense.)