LokQL.
A local-first data flow and virtual query layer for large structured browser datasets, using workers, SQLite Wasm, OPFS, and virtualized windowed queries.
Large structured tables in the browser should not require loading the full dataset into main-thread memory.
LokQL targets the gap between spreadsheet-like tables and databases: structured in-browser data that stays responsive as it grows beyond what simple arrays can handle.
The design keeps data on the client, moves query work into workers and Wasm, and virtualizes results so the UI never waits on a full scan.
Worker, storage, adapter, and query contracts stay replaceable so the data path can evolve per runtime constraints.
- L1SQLite Wasm core
SQLite compiled for the browser manages structured tables, indexes, and windowed queries without leaving local storage.
- L2OPFS persistence
Origin-private file system stores larger datasets persistently, avoiding quota pressure on the main JS heap.
- L3Virtual query layer
Windowed results, keyset navigation, and worker-side filtering keep rendering fast regardless of underlying row count.
Contracts over hacks: storage, worker, and adapter boundaries make large shifts replaceable.
Data stays in the browser, reducing sync dependency and letting the product work offline with a clear migration path.
The UI renders only visible slices while queries execute in workers, bounding interaction cost for large datasets.
Storage, worker, and adapter interfaces are defined as contracts so backends can evolve without rewriting the query path.
The result is a query surface that stays usable as datasets grow beyond what plain arrays can comfortably hold.
Worker-isolated queries
Filtering, aggregation, and scanning run off the UI thread so the page stays responsive during heavy work.
SQLite Wasm
A real query engine inside the browser gives SQL-style semantics without shipping rows to a remote service.
OPFS persistence
Large structured data can live durably in origin-private storage instead of bloating small-row in-memory state.
Benchmark + release checks
Release checks, benchmark smoke tests, and docs consistency gates keep performance regressions from sailing through.