Postindex

The workload is filters. An issue tracker holds a few hundred thousand documents and almost every read is a conjunction over them: two tags, one of three statuses, an assignee, a date window. The documents themselves are small. What costs you is deciding which ones come back.

So this is a filter engine before it is a database. Exact fields become posting lists held as roaring-style containers, sparse ones as sorted arrays and dense ones as bitmaps, promoted at 4096 entries. Intersection dispatches per container pair instead of materialising one dense bitmap, and a query can stream matching ids without ever building one. Segments are immutable and merge LSM-style. The catalog is a plain B-tree map, because it is small and stays in memory.

Against IndexedDB the argument is short. It is a key/value store with no way to intersect two filters, so you fetch candidates and filter them in JavaScript. Against SQLite compiled to WebAssembly it is much narrower, and not all in one direction: SQLite gives you a planner, joins and range scans today, and this gives you none of those yet. What it gives instead is a bitmap-shaped intersection path where a row store walks tuples.

The costs are real. Rust on wasm32 with no third-party crates means the codecs, the checksums and the WAL framing are all hand written. A virtual filesystem six calls wide sits between the engine and OPFS, because wasm cannot hold a file handle itself, and the browser can kill the tab mid-write with no warning.