tracks04 / 04❯ embedded — in your process

put it in your own binary

The core of Rindle is a std-only Rust crate — no server, no runtime, and it ships as ~200 kB gzipped of wasm. Embed it next to your data, feed it writes, and either take materialized views or fold the raw delta stream yourself. Everything you embed and ship is open source (Apache-2.0) — and when readers multiply, the same queries scale onto a read fleet.

the crates →fold deltas in rust

01 · three ways in

one engine, wherever your process runs.

The same query API and the same correctness contract — view-after-write == fresh-query — behind every door. Pick by where your data lives.

rustrindle · rindle-sqlitein your binary

The open IVM core: std-only, C-toolchain-free, single-threaded by design. Add views over the in-memory tree or SQLite, or attach a change sink and take the raw stream.

docs →node@rindle/replicain your server

Native SQLite in-process — durable writes with BEGIN CONCURRENT CDC, live derived reads, the same fluent query API as the browser.

docs →browser@rindle/wasmin a tab

The same engine compiled to wasm — ~200 kB gzipped: local-first reactive reads over a local database, no server in the loop.

docs →

02 · the raw delta stream

fold it yourself.

Skip the built-in views entirely: attach a change sink and the engine hands you the incremental CaughtChange stream — Add / Remove / Edit / Child. Maintain your own structure, forward it over a wire, persist it. A view folded from the diffs alone equals a fresh query, and the engine is tested that way: differentially, against a SQLite oracle, by a coverage-driven fuzzer.

match ch { CaughtChange::Add(n) => { view.insert(pk(&n.row), render(&n.row)); } CaughtChange::Remove(n) => { view.remove(&pk(&n.row)); } CaughtChange::Edit { old, row } => { view.remove(&pk(old)); view.insert(pk(row), render(row)); } CaughtChange::Child { .. } => { /* nested relationship diffs */ }}

The runnable version ships with the crate: cargo run -p rindle-sqlite --example fold_deltas — it maintains a view from the stream and proves it equals a fresh SELECT.

03 · measured, not promised

small enough to embed, fast enough to trust.

~430nsper incremental update, in-process

flat·30×cost holds as the dataset grows 30×

200kbthe whole engine, gzipped, to wasm

0c depsstd-only core; no c toolchain to link

04 · when readers multiply

the same queries, scaled out.

The embedded core is single-threaded on purpose. When one process stops being enough, nothing about your queries changes — the rindled daemon runs the multi-threaded Cluster engine (queries sharded across IVM workers under snapshot isolation), and a replicated read fleet fans further out through follower affinity. The client engine stays free wherever you embed it; production is one flat license sized by your team — scaling the fleet costs nothing extra.

scale the reads →see pricing

05 · ship it

your docs path: use the engine.

The crates are the docs' engine path: the core and the fluent builder, the change model, the SQLite backend — then the daemon and the read fleet when you outgrow one process. Start where your data is.

start with the crates →see the numbers browse the whole path →