Rindle is one incremental view-maintenance engine that runs everywhere your data lives, behind one query API and one correctness contract. It takes over the three things every app reinvents and most get subtly wrong — live queries, the cache, and optimistic updates. This page is the honest version of “should you use this.”
What it replaces
The status quo for “keep this query fresh on the client” is a stack you assemble by hand:
- a WebSocket or polling layer to push updates,
- a client cache and the invalidation logic to keep it from going stale,
- bespoke optimistic-update code per mutation, and the rollback logic when the server disagrees,
- and a pile of refetch-on-focus / refetch-on-reconnect heuristics to paper over the gaps.
Rindle collapses that into: write a query, materialize() it, and write through
named mutators. The engine keeps the result exact — view-after-write equals a
fresh query — and the local-first client makes reads
instant and writes optimistic, rebased by the engine itself: deterministic
mutators re-run against the server’s authoritative result, so read-dependent
writes recompute correctly and a rejected write snaps back with zero rollback
code. There is no separate cache to invalidate, because the engine derives every
view from the data and keeps it correct by construction.
Who it’s for
- App developers who want live, reactive queries with optimistic updates and don’t want to build (or operate) a sync stack. → Start with the local-first client.
- Platforms that generate apps for others — app builders, internal-tool platforms, AI app generators. Rindle is a small, embeddable engine you can drop into every app you ship, so live queries and optimistic updates come for free in the generated output instead of being something each app has to get right.
- Systems / Rust engineers who want embeddable IVM as a library —
std-only, single-threaded, no hosted dependency. → Start with the crates. - Teams replacing a read-model / cache layer server-side — derive live views off a SQLite replica fed by CDC, instead of cron-refreshed tables and Redis invalidation. → Start with replica & views.
How it compares
The comparison here isn’t about query semantics — it’s about shape. Rindle is the embeddable engine, not a hosted product: the same correctness contract, on your infrastructure, at every tier.
| Rindle | Typical alternative | |
|---|---|---|
| Hosted reactive backends (Convex, etc.) | self-hosted or embedded; your data, your cloud; runs in the browser too | turnkey and managed, but their service, their runtime, their lock-in |
| Sync frameworks (KV + hand-written mutators) | you write queries + deterministic mutators; the engine derives the result and rebases optimistic writes itself | you write mutators and diffs by hand against a KV store, and own the rebase semantics |
| Postgres→local sync (ElectricSQL, etc.) | backend-agnostic; one engine over wasm, native SQLite, or the wire | tied to Postgres logical replication and a specific topology |
| Warehouse-scale IVM (Materialize, differential dataflow) | small enough to run in a tab; client-first | server/cluster-scale, not embeddable on the client |
| Hand-rolled (WebSocket + cache + invalidation) | one engine, one contract, optimistic + local query resolution built in | N moving parts you own and debug forever |
When Rindle is not the answer
Being honest about the edges:
- You want a fully managed, zero-ops product. Rindle is self-hosted / embedded — you run it. If you’d rather not operate anything, a hosted backend fits better.
- You need rich multi-party offline conflict resolution today. Rindle’s write model is server-authoritative: optimistic locally, rebased against the server’s result. That’s the right model for most apps, but it is not a general CRDT merge engine.
- Your query is outside the supported shape. The engine covers a large, growing subset honestly documented in supported queries — check it against what you need.
Next steps
- Overview — what Rindle is, in one page.
- The local-first client — the high-level story: optimistic, instant, synced.
- Reactive queries in the browser — the primitive underneath: one runtime, no server.
- Performance — the measured cost of incremental maintenance.
- Supported queries — exactly what builds today.