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. This page summarizes benchmark results from the benchmarks/ suite in this repository.

Summary

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 gap on long-text queries with complex filters. Indexing throughput is effectively identical between the two engines.

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 is ~350–1,270% faster than 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.

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 smaller bundle with ZBSearch 3.3.0:

The index portion of the bundle shrinks the most (~11.6% GZIP on index data alone) thanks to delta-encoded postings and dropping redundant tokenOccurrences from the serialized snapshot.

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              # core insert/search
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

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