ZBSearch vs Orama

ZBSearch is a fork of Orama maintained by the original engineering team. The API is compatible, but the internals have been optimized - including an explicit postings list inverted index that lowers memory use and serialized bundle size while keeping search fast, a faster full-text insert path, and an optional IVF vector index. This page summarizes benchmark results from the benchmarks/ suite in this repository.

Summary

Head-to-head: 20 metrics, one run

The benchmark:compare suite runs both engines through the same 20 workloads in a single process. ZBSearch 4.0.0 wins 18; Orama wins the two bundle-size metrics.

Speed metrics are ops/sec (higher is better); indexing/remove are median latency and memory/bundle are bytes (lower is better).

Core full-text search

Dataset: 1,512 video-game records with title, description, rating, and genres fields. Search benchmarks run against a database populated once before timing; insert benchmarks create a fresh database on each iteration.

ZBSearch is faster across all search scenarios tested here, with the largest gaps on plain search and long-text queries with complex filters. Indexing is also substantially faster (~1.7× Orama) thanks to node-local postings caches and a tighter tokenize/insert path.

Search quality (BEIR)

Throughput without relevance is meaningless, so ranking quality is measured on standard BEIR collections with official relevance judgments, using exact trec_eval semantics. Both engines run with their own ecosystem's stopwords and stemmer. The published Lucene BM25 nDCG@10 is shown as a reference point.

ZBSearch's BM25 lands in the same band as the Lucene reference on every dataset (and above it on SciFact), while Orama scores less than half of ZBSearch's macro average - at roughly 3× the per-query latency. Full per-engine tables (including MiniSearch, FlexSearch, Lunr, and Fuse.js) are on the benchmarks page.

Facets

Vector search

Dataset: 2,000 documents, 128-dimensional vectors.

ZBSearch IVF vs Orama flat

ZBSearch adds an optional IVF index for approximate nearest-neighbor search. Orama does not ship an equivalent in the JS core.

With IVF (nlist=179, nprobe=16), ZBSearch vector search runs at 3.2–5.3× the throughput of Orama's flat index on this dataset.

Geosearch (BKD tree)

Dataset: 10,000 geopoints.

The largest geosearch gain is on tight-radius queries, where ZBSearch's BKD implementation avoids scanning the full point set.

Sorted indexes (AVL tree)

Dataset: 10,000 numeric keys.

Inverted index (postings)

Starting in 3.3.0, ZBSearch stores full-text doc IDs in explicit posting lists outside the radix tree dictionary. The radix tree handles prefix navigation and typo tolerance; postings map each token to its document IDs.

This removes duplication that existed between inline radix Sets, tokenOccurrences, and scattered serialization of doc ID arrays. On save, posting lists are delta-encoded (sorted doc IDs stored as gaps), which shrinks the bundle without changing search semantics.

At runtime, document frequency for BM25 is derived directly from posting list length - no separate counter map is maintained. Leaf nodes also keep a direct reference to their posting array so inserts can append without a map lookup on every token.

Memory footprint

Measured in isolated Node.js processes with --expose-gc, after indexing all 1,512 records and running 100 warmup searches. Heap delta is the increase over a GC'd baseline after the index is built - the most apples-to-apples comparison.

Search working-set memory is effectively the same; the savings come from the index structure itself.

Persistence size

Serializing the same indexed dataset produces a much smaller bundle with ZBSearch 4.0.0:

Delta-encoded postings and dropping redundant tokenOccurrences from the serialized snapshot account for most of the reduction. v4 also adds a chunked persistence format for indexes that outgrow a single string.

Run the benchmarks yourself

From the repository root, build ZBSearch first, then run any suite in benchmarks/:

cd packages/zbsearch && npm run build
cd ../../benchmarks && npm install

npm run benchmark:compare      # Orama vs ZBSearch, 20 metrics
npm run benchmark              # core insert/search
npm run benchmark:algorithms   # BM25 vs QPS vs PT15
npm run benchmark:facets       # facet workloads
npm run benchmark:vector       # vector search (flat)
npm run benchmark:vector-ivf   # vector flat vs IVF
npm run benchmark:bkd          # geosearch BKD tree
npm run benchmark:avl          # sorted AVL tree
npm run benchmark:bundle-size  # serialized DB size
npm run benchmark:memory       # in-memory heap/RSS footprint
npm run benchmark:search-quality # BEIR ranking quality

Results are saved as JSON and HTML charts under benchmarks/benchmark/results/.