kevy · wasm playground

A real KV engine, running in this tab.

Not a mock. This is kevy compiled to WebAssembly — storing durably in OPFS, answering reads in-process, and carrying pub/sub across your browser tabs. Everything below runs locally; nothing leaves the page.

engine booting… persistence keys 0 tab

Durable storage

OPFS · survives reload

Write a key, then reload the page. The value is still there — it was flushed to origin-private storage, not kept in a variable.

booting…
keys 0 last op

Cross-tab pub/sub

BroadcastChannel · sub-ms
Open this page in a second tab, then publish from either one — both receive it live.
not subscribed
received 0 last hop

Against the browser's own storage

runs live, on your machine

The honest comparison: kevy versus what the platform already gives you. Same workload, same tab, measured right now — including the axis kevy loses.

“But kevy’s own write log can land in IndexedDB — isn’t that circular?” No, and the distinction is the whole point. IndexedDB here is a block store: kevy appends a batched byte log to it, off the hot path. It is never on the read or write path — every operation runs inside wasm linear memory. Using IndexedDB to hold a log is not the same as using it as the key-value engine, which is what the bars below measure. OPFS is the primary backend; IndexedDB is the fallback where OPFS synchronous handles are unavailable.

ops per engine