Powered by RoaringRange
This RoaringRange demo can search OpenAlex works entirely in your browser, with no backend — or hand a query to a tiny regional Lambda when you want raw speed (the trigram default). Either way the index is one static file on S3, and a query fetches just a few small byte-ranges over HTTP — never the whole file. It's powered by RoaringRange, and inspired by Lunr.js and Pagefind.
Each OpenAlex Work — a paper, book chapter, dataset, preprint — becomes one ranked document.
Documents are numbered by cited_by_count, most-cited first, which is exactly what lets the popular “head” paint instantly.
The searchable text of each work is concatenated and cut into trigrams, so a query matches across any field —
a phrase from the abstract, an author, or a journal, not just the title.
OpenAlex doesn’t ship abstracts as plain text; it stores an abstract_inverted_index — a map of
each word to the positions where it occurs — so the builder reconstructs the running abstract from that
index before indexing it (that’s what the abstract ← abstract_inverted_index chip below means).
The same text is indexed a second way — as whole words, not character trigrams.
This term index (the .rrt file) Snowball-stems each word and stores one posting per term,
so a query word costs a single fetch carrying that word’s true rarity — strongest for exact
and prefix/autocomplete matches, where trigrams shine at substring and typo-tolerant search. Both indexes
share the same doc IDs, so a query can use either or fuse them; both formats sit side by side in
section 04.
Five fields from each work become filter categories — the .rrf sidecar. Counts are free; selecting one fetches a single small posting.
article, book-chapter, dataset, preprint, …The record behind each hit keeps just enough to render a card and link out — opaque bytes the format never inspects.
Example result card
Deeper neural networks are more difficult to train. We present a residual learning framework to ease the training of networks that are substantially deeper than those used previously… abstract
id W2194775991 → openalex.org/W2194775991
A small companion index — the .rril file — maps each work’s DOI straight to its document.
Pasting a DOI, or a doi.org URL, jumps to the exact work in a couple of byte-range reads instead of a text search.
The format appears in section 04.
A query tokenizes into trigrams, fetches matching dictionary blocks and each trigram’s eager prefix as parallel HTTP Range requests,
ANDs the roaring bitmaps, and reads the page’s records — a few KB–MB in total. The multi-GB file is never downloaded whole.
One query, a near-constant number of round-trips — independent of corpus size.
Range requests, ANDs the roaring bitmaps, and reads the page’s records. The multi-GB file is never downloaded whole.Two tiers in time: each posting’s first bucket paints first, then the deeper buckets fill in.
Boot is cheap because only the small top of each file loads up front.
Trigram search matches characters — exact substrings. Semantic search matches meaning:
the query and every work become vectors, and the nearest by cosine win — even with no shared words.
Same static ethos — an IVFPQ index (the .rrvi file) boots once, and each query
range-fetches only a few clusters.
The corpus is partitioned into nlist clusters by coarse centroids, and every vector is stored as a
compact product-quantization code — 32 bytes, not a 2 KB float array — optionally rotated
by OPQ for accuracy. Boot downloads the small boot region once: the OPQ rotation, the centroids,
the PQ codebooks, and a cluster directory. Per query, the reader finds the nprobe nearest centroids
in memory, range-fetches just those clusters’ code lists, and ranks them by asymmetric distance
— the real query vector scored against quantized codes through precomputed tables, no full vectors needed.
The query path mirrors the trigram one — a near-constant number of round-trips, independent of corpus size.
nprobe nearest centroids from the in-memory boot region, and range-fetches only those clusters’ PQ codes to rank by asymmetric distance. Out come ranked doc IDs in the same numbering as the text index — so records render through the very same path.
The search machinery is identical; only the embedder differs. Each model defines its own vector space,
so each embedder has its own .rrvi — but the corpus is embedded once, offline, for $0 either way.
potion-retrieval-32M) ported to wasm: tokenize (BERT WordPiece), average
the per-token vectors, normalize. No neural net, no API key, $0. The token matrix
(.rrm2, ~33 MB int8) downloads once and is browser-cached. Slightly lower quality than a transformer.
EmbeddingGemma-300M runs in a Lambda as ONNX (no PyTorch), fronted by CloudFront. A real
transformer with asymmetric prompts (query: vs document:) gives stronger
paraphrase recall; ~40 ms warm. Only the live query calls it — the corpus was embedded locally.
Vectors reuse the exact doc-ID numbering of the text index and the facet sidecar
(vector_id == doc_id) — so the same roaring-bitmap facets apply with no remapping.
Filtering a semantic search keeps only the candidate IDs that fall in the selected category bitmaps,
the same membership test the trigram path already does. Two strategies trade recall for simplicity:
Counts are computed over the retrieved candidate pool rather than a complete bitmap — “semantic matches” is a ranked list, not an exact set — with the same in-wasm machinery and no backend. And hybrid inherits all of it: it fuses the filtered trigram and filtered semantic lists.
Run both. Trigram nails exact terms (names, identifiers, rare phrases); semantic catches paraphrase and synonymy.
Reciprocal rank fusion blends the two ranked lists without needing comparable scores: each list contributes
1 / (k + rank) to a doc (k ≈ 60), so anything near the top of either ranks high.
nprobe nearest clusters’ code lists ([u32 ids][u8 codes]). An optional .rrm2 (model2vec static matrix) and .rrvr (bf16 full-vector re-rank sidecar, fetched only for the surviving top-K) ride alongside. The whole index is never downloaded.One static text index plus a family of companion files. Every box below loads by HTTP byte-range; nothing runs server-side. Doc IDs are assigned by citation count throughout, so the most-cited works sit in the “head” and top-K is free.
Every artifact below is a standalone static file (or a set of them) sharing one global doc-ID space, so they compose à la carte — pick the indexes a query needs and ignore the rest. The demo publishes the whole family over the full OpenAlex corpus, 484,369,476 works; each box loads by HTTP byte-range.
doi.org URL, straight to its doc ID in a couple of reads.TailScan) only as a query needs them. Boot keeps the header + sparse index in memory; each query binary-searches it, fetches one dictionary block, then each trigram’s eager prefix..idx) maps a doc ID to a byte range in the record blob (.bin) — two ranged reads, and a page of consecutive IDs is one contiguous slice. Records are opaque bytes, so the format never dictates your data model..rrsc column lets the reader fetch one value per candidate and top-K client-side (sort by date, rating, any metric), ties broken by doc ID. The same container also backs a full second index: a u32 permutation column maps secondary_docid → primary_docid, so a results page — a contiguous run — resolves back to primary IDs in a single ranged read.tantivy-sstable shape) with a small resident FST routing over block boundaries — only the router (O(#blocks)) stays in memory while the dictionary blocks range-fetch on demand, so a full-corpus vocabulary loads in a browser. Each query word costs one block read plus one posting read, versus ~(L−2) trigram fetches; stemming and stop-word removal are recorded in the header so the reader tokenizes queries identically. The postings region is byte-identical to the trigram .rrs, so doc IDs and the head/tail rank split carry straight over..rrb sidecar adds the missing relevance signal: at build time, BM25’s per-document half (term frequency saturated by k1, normalized by document length) is computed and quantized into one byte per (word, doc); at query time the reader takes the first M matches, fetches just those candidates’ bytes, and reorders them by Σ idf × impact. The trick that keeps it additive: impact bytes are stored in each word’s posting order, so the roaring bitmap the search already fetched is the addressing structure (rank(doc) names the byte) — no term IDs, no norms file, and the .rrt itself is byte-identical to before. Because every index shares the doc-ID space, the same sidecar can rerank trigram and hybrid candidates too..rrs (or .rrt) — one split is exactly today’s monolith — and only the manifest (.rrss) is new, carrying the cross-split pruning metadata (rank tier, doc-ID range, byte size, and optional term-Bloom / facet-presence / tombstone summaries). The bandwidth win is pruning, not log-structuredness: because doc IDs are rank-ordered, a top-K query reads only the top tier and leaves the cold tail in S3. The tiers size geometrically (per-tier byte caps double down the rank order), so a worst-case descent is ~log-many split visits, and a small base + delta lifecycle absorbs freshly-added docs without a full rebuild. The demo publishes a 19-tier trigram set and a 12-tier term set; each manifest is ~1 KB (no per-split summaries), so the whole set boots in one GET.
The unit of cost is bytes moved per query — this demo’s link is bandwidth-bound
(measured ~1–3.5 MB/s down, ~150–200 ms RTT), so per-query bytes, not CPU, set wall
time. Storage is nearly free — the full 484M index family (trigram monolith + term + vector +
records + facet sidecars + the geometric trigram and term split sets + the BM25 .rrb
sidecar, ~550 GB) is about $13/month on S3 — and there is no idle cost. Trigram
defaults to a regional /search Lambda (~1–3 KB, ~0.66 s, faceting
included); the client-side range-read modes — searchable with no backend at all —
are one toggle away, and that’s where bytes climb.
What grows with the corpus is the density of common postings — a trigram like ing
appears in a constant fraction of documents, so its bitmap grows linearly with the corpus. Measured per
query at 484M, by mode (with the one-time resident boot each mode pays on first use):
| mode (484M, warm) | per query | resident boot |
|---|---|---|
| trigram — server (default) | ~1–3 KB | none |
| trigram — client geo split | ~240–300 KB | ~1.5 KB |
| trigram — client monolith | ~0.87–1.07 MB | ~1.7 MB |
| term — client geo split | ~40–270 KB | ~1 KB |
| term — client monolith | ~15–20 KB | ~76 MB |
| semantic (8 IVFPQ probes) | ~2–9.6 MB | ~64 MB |
| records page (25 cards) | ~25–50 KB | — |
| client facet filter (membership) | ~tens of KB | — |
| server facet filter | ~2 KB (+ exact counts) | none |
The split sets cut client bytes by pruning (read only the tiers that can match) and geometric
tiering caps a worst-case descent at ~log-many visits. Faceting is cheap client-side too: the demo
post-filters the ranked candidates with a membership read — only the 64K-doc buckets the
candidates occupy (container-granularity seeks on the .rrf), not the whole category bitmap
— so a category that's tens of MB whole costs ~tens of KB here, and counts come free from the
resident facet heads. The server’s facet edge is exact totals + counts, not bytes. The
sweet spot is large corpus × modest traffic, and it widens as the corpus shrinks:
per-query bytes scale with the corpus, so a smaller index makes the client-side path cheaper and
the CDN free tier go further. The demo runs the full 484M corpus.
Behind CloudFront (1 TB + 10M requests/month free), baselined on the server default (~2 KB/query) and a representative client query (geo split, ~0.3 MB / ~30 range-GETs). The Lambda runs the same intersection over the same files, in-region where S3 bandwidth is free, returning only result IDs + facet counts.
| queries / month | server default (this) | client range reads | always-on server | managed search |
|---|---|---|---|---|
| 10k – 100k | ~$13 (inside free tier) | ~$13 | ~$100–150 flat | $700+ |
| 1M | ~$20 | ~$30–50 | ~$100–150 | $700+ |
| 10M | ~$110–150 | ~$300–400 | ~$150+ | $1,500+ |
So the demo’s production shape is now server-side by default with the client-side range-read modes as the no-backend option. And because the dictionary records every posting’s byte size, the client can estimate a query’s cost before fetching anything and auto-route the expensive ones to the Lambda — the “server-side search” toggle is that routing made explicit.