STOP 01
Documents flow in. The engine addresses every passage as a byte-exact row —
handing row ids to the vector store and writing content rows to
.spdb files, the data store.
STOP 02
A local agent ingests and retrieves against on-device .spdb storage — no server.
When the device fills up, SpeedyDb spills to a cloud instance for storage and retrieval.
A policy gate decides what leaves the device: sync everything, or keep sensitive files on-device.
STOP 03
The same engine drops into your app as a ~0.7 MB library — no browser quota to fight. The application (or its user) sets the storage budget; SpeedyDb keeps data within it, reserving model + index space first and evicting cloud-backed cold data before anything local-only.
STOP 04
One cloud-backed context, linked across your browser, your application, and other people. Access is scoped by a privacy policy — grant or restrict per user, or per group.
STOP 05
No process-resident cache — reads are served from the reclaimable OS page cache, and the binary is ~0.7 MB. So the memory budget stays free for the things that actually need it: local models, vector DBs, and your coding tools.
STOP 06
Point SpeedyDb's lazy scan_spdb engine at a columnar .spdb and run
the pandas you already write — filter, groupby, sort,
value_counts, assign. Same answer, often faster, at a
fraction of the memory and CPU: it streams from disk and decodes only the columns
each op touches, so it never materializes the whole frame the way pandas must to
be quick.
The same streaming discipline is already serving agents over MCP — combine, filter, aggregate, pivot and outlier removal, each bounded, with peak memory measured well under the size of the input. Try it on a file of your own.
STOP 07 · LAST STOP
Load a file or our samples — chunked and stored by the real SpeedyDb engine compiled to WebAssembly, entirely on-device and saved in your browser's own storage. Then hit next and ask: RAG search returns the exact stored passages; Agent search has an on-device model write a grounded answer from them. Nothing ever leaves the page.
ingest files, search your sources, and ask an on-device agent — all client-side, nothing leaves the page.
Transform a table →upload a CSV, ask in plain English, download the result — an on-device model picks the operation and the MCP server streams it, so a file larger than memory is answered slowly rather than not at all.