docs · incremental view maintenance

build a synced app.

one engine that keeps a query's result live as the data changes, across three tiers: an optimistic browser client, a stateless API authority, and an always-up daemon. it takes over the three things every app reinvents: live queries, the cache, and optimistic updates. one schema, one builder, one contract (view-after-write == fresh-query).

start here · the three-tier architecture@rindle/optimistic · @rindle/api-server · rindledthe whole synced app: the browser runs its own engine over its own local database; a stateless API server is your authority; the rindled daemon holds the data and streams normalized updates. optimistic now, authoritative on confirm, snapped back on rejection.read the story →

the three tiers, one at a time

browser client@rindle/optimistic · @rindle/wasm · @rindle/reactits own engine over its own local database: instant local reads, optimistic writes rebased by the engine as the server confirms.get started →API server@rindle/api-server · @rindle/daemon-clientyour app's authority — stateless, serverless-shaped. resolves named queries to ASTs and runs the authoritative mutators into approved SQL.get started →daemonrindledthe always-up server you run like Postgres. holds the data + the live IVM pipelines; streams normalized updates over a two-plane wire.run it →

or use the engine directly — same code, no server

browser engine@rindle/wasmthe engine compiled to wasm, queries running in-process. reactive reads with no server, in ~228 kB gzipped.get started →node replica@rindle/replicanative SQLite with BEGIN CONCURRENT CDC, in-process. real durable writes, live derived reads.get started →rust corerindlethe std-only IVM core, embedded directly. build a pipeline, hydrate a view, push changes.go deeper →

worked examples

start & concepts