# Is Rindle for you? Who Rindle is for, what it replaces, how it compares to hand-rolled stacks, sync frameworks, hosted reactive backends, and warehouse-scale IVM — and the workloads it's wrong for. Rindle is **one incremental view-maintenance engine** that runs everywhere your data lives, behind one query API and one correctness contract — folding in the **live queries**, **caching**, and **optimistic updates** an app would otherwise hand-build and maintain. This page is the "should you use this?": who it's for, what it replaces, how it stacks up, and where it isn't the right tool. ## 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](/docs/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](/docs/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](/docs/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](/docs/replica-and-views). ## How it compares The comparison here isn't about *query semantics* — it's about **shape**. Rindle is an *embeddable engine* with the same correctness contract at every tier — run it yourself, or let us run it for you on [Rindle Cloud](https://cloud.rindle.sh). Either way it's your data and your contract, not a black-box runtime you can't audit or move off of. | | Rindle | Typical alternative | | --- | --- | --- | | **Hosted reactive backends** (Convex, etc.) | self-host, embed, *or* managed Rindle Cloud — your data, your contract, 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 Managed-vs-self-hosted is **not** one of these limits: if you'd rather not operate anything, [Rindle Cloud](https://cloud.rindle.sh) runs the same engine and the same correctness contract *for* you instead of *by* you (see [deploying & scaling](/docs/deploy) for the full menu and what's managed today). The limits below hold either way: - **Your bottleneck is sustained write throughput beyond one logical master.** A Rindle deployment accepts concurrent HCTree transactions at one write master and commits them into the total order that lets every replica and client converge. More connections and execution threads scale that master up; sharding by tenant scales writes out. Write-throughput-bound firehoses (high-frequency telemetry, clickstream ingest) are the wrong shape. The [fit guide](/blog/what-rindle-is-for) walks through exactly where that line is. - **You need ad-hoc analytics over large, cold datasets.** Rindle maintains *defined* queries incrementally; it is not a column store and won't win a full-table scan over hundreds of millions of cold rows. A bounded, pre-declared aggregate kept live? Yes. The whole warehouse, ad-hoc? No. - **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 documented in [supported queries](/docs/supported-queries) — check it against what you need. ## Next steps - [Overview](/docs/overview) — what Rindle is, in one page. - [The local-first client](/docs/client) — the high-level story: optimistic, instant, synced. - [Reactive queries in the browser](/docs/wasm-client) — the primitive underneath: one runtime, no server. - [Performance](/docs/performance) — the measured cost of incremental maintenance. - [Supported queries](/docs/supported-queries) — exactly what builds today. --- [View this page on Rindle](https://rindle.sh/docs/compare)