Rindle fits applications that need the same queries to stay current through many changes. Common examples include issue trackers, collaborative tools, live dashboards, and derived read models.
The engine maintains query results from changes to the underlying rows. The synced-app packages add local reads, optimistic writes, and reconciliation with a server that controls the authoritative data.
What it replaces
A live application often combines polling or WebSockets with cached results, invalidation rules, optimistic updates, and rollback logic. Every new query or mutation adds another place to keep those rules consistent.
With Rindle, a materialized query stays current as its source data changes. The engine derives each view from those rows. You subscribe to the result instead of defining a refresh rule for that view.
In a synced app, named mutators describe the writes. The client applies them optimistically, then reruns pending mutators against authoritative updates. Rejected writes disappear from the local result. Your application still handles authorization, validation, and messages that explain rejected writes to users.
These responsibilities differ by integration. The embedded engine maintains views over the rows you supply. The synced client and server packages provide the sync and optimistic-write workflow.
Who it’s for
- Application teams that need live lists, related records, and responsive writes across users. Start with the app scaffold.
- Teams with derived read models that need fresh results after source changes. Start with replica & views.
- Browser application developers that need reactive queries over local data. Start with the browser engine.
- Rust embedders that need SQLite storage with live queries in their own process.
Start with
rindle-replica. Use the raw engine when your application supplies row changes directly. - Browser integrations that need server results with optional local execution or optimistic writes. Start with the client chooser.
How it compares
The useful comparison is the responsibility you want Rindle to take over. The choice depends on your data and application.
| Approach | What it provides | What to consider |
|---|---|---|
| Fetch requests and a client cache | Explicit requests, stored responses, and refresh controls | A practical fit for occasional reads. Frequent related updates require invalidation rules. |
| Custom WebSocket sync | A transport for events or data | You define how events update each query result and reconcile optimistic writes. |
| Raw Rindle engine | Live views over the rows your application supplies | You manage data ingestion, persistence, and any network transport. |
Embedded rindle-replica |
SQLite storage, SQL write capture, and live query events | Your process owns the database lifecycle and uses the controlled writer. |
| A synced Rindle app | Local queries, synchronized data, and optimistic reconciliation | You define authorized queries and deterministic mutators, and deploy the application tiers. |
| An analytical database | Queries over large datasets and broad analytical workloads | A better fit for large scans and ad-hoc analytics than an engine embedded in a browser. |
The Rust manifests for the engine, SQLite backend, replica runtime, daemon, and replicator declare Apache-2.0. The crate and package map describes their APIs and distribution status. Deployment options describe the available server arrangements.
When Rindle is not the answer
- Your data rarely changes. A fetch request can be enough for a static page or occasional report. A maintained query adds state that such workloads do not need.
- You need unrestricted SQL for live queries. Rindle maintains a defined set of query shapes. Its typed query builder does not turn every SQL statement into a live view. The query reference lists the supported shapes and restrictions.
- You need general offline conflict merging. The synced write model uses a server as the authority. Pending local writes rebase against that server’s result. Rindle is not a general CRDT merge engine.
- Your workload requires more writes than one logical master can sustain. A replicated deployment orders writes through one master. Read followers increase read capacity. They do not distribute writes across multiple masters.
- You need ad-hoc analytics over large, cold datasets. Rindle maintains registered queries. A warehouse or analytical database is a better starting point for large scans and broad aggregation.
Incremental maintenance also has a cost. Initial queries must read their starting data. Later writes can affect many rows through relationships. Actual work depends on the query, indexes, result size, and changes. The performance guide explains the measured workloads.
Next steps
For an in-process experiment, start with reactive queries in the browser. For an application shared across users, start with the app scaffold. Getting started also covers SQL services, server read models, embedded runtimes, and PostgreSQL integration.