benchmark comparison

altor-vec vs Voyager

Browser-first vector search alternatives with different algorithm and packaging tradeoffs.

When both options are already browser-aware, the decision usually becomes empirical. Small differences in packaging, defaults, and recall/latency tradeoffs matter more than sweeping architectural arguments.

These numbers are representative, not universal. Bundle size, query latency, and memory usage all vary with vector dimensions, index parameters, browser runtime, hardware, and whether embeddings are generated on device or ahead of time.

Comparison table

Category	altor-vec	Voyager
Runtime model	Client-side WASM ANN focused on a small integration surface.	Browser-capable vector search alternative with its own algorithm and packaging assumptions.
Bundle size / delivery	~54KB gzipped representative payload.	Often somewhat larger depending on packaging and chosen build output.
Query latency	Fast local lookups intended for interactive frontend UX.	Also optimized for local search; benchmark directly because browser performance is corpus-specific.
Memory usage	Index lives in client memory.	Similar client-memory story with implementation-specific overhead.
Features	Compact ANN API and serialized local index workflow.	Competing browser vector search capabilities with different integration choices.
Dataset sweet spot	Moderate corpora bundled into the app.	Similar browser-delivered dataset sizes.

Where altor-vec wins

Small payload and simple API shape.
Strong fit when browser delivery friction is the first concern.
Good option for teams that want minimal surface area.

Where Voyager wins

May hit better recall or latency on some corpora.
Alternative algorithmic tradeoffs could suit certain embedding distributions better.
Existing user familiarity may reduce switching costs.

Honest decision guide

At this tier, benchmark on your own corpus. Developer experience, bundle budget, and how predictable the results feel in the browser often decide more than theory alone.

The honest pattern across all of these benchmark pages is simple: if the search corpus should stay on the server, choose server-oriented infrastructure. If the search corpus is intentionally shipped with the product and the UX benefit of local retrieval matters more than backend scale, altor-vec is usually the more natural fit.

FAQ

Is one clearly better than the other?

Not without a corpus-specific benchmark. Browser ANN comparisons are highly dependent on vector shape and index parameters.

What matters more than theoretical speed?

How easy it is to ship, load, and operate in the product bundle.

Why can a smaller library win even if raw performance is similar?

Because frontend teams also pay in startup time, build complexity, and maintenance overhead.

Get started: npm install altor-vec · GitHub

Benchmark methodology

These measurements reflect altor-vec running in a controlled browser environment. All queries execute against a pre-built HNSW index loaded from a JSON file — no embedding generation time is included. Embeddings are generated once at build time.

Parameter	Value
Index size	10,000 vectors
Dimensions	384 (all-MiniLM-L6-v2)
HNSW M	16
ef_construction / ef_search	200 / 50
k	5
Browser	Chrome 124, M2 MacBook Pro
Measurement	p50/p95 of 1,000 consecutive queries

altor-vec latency (10K × 384d)

Metric	Result
p50 query latency	0.4ms
p95 query latency	0.8ms
Index load time	~35ms
Memory footprint	~17MB
WASM bundle size	54KB gzipped

What these numbers mean

Sub-millisecond latency means search is effectively instant from the user's perspective. Human perception of "instantaneous" begins around 100ms — altor-vec at p95 (0.8ms) is 125× faster than a cloud search call at 100ms total round-trip.

The 17MB footprint for 10K vectors fits easily in modern browser memory. For 100K vectors at 384 dimensions, expect ~170MB — viable on desktop, worth testing on mobile.

Run your own benchmark

import init, { WasmSearchEngine } from 'altor-vec';
await init();
const engine = WasmSearchEngine.from_vectors(vectors, DIM, 16, 200, 50);
const query = new Float32Array(DIM);
const times = [];
for (let i = 0; i < 1000; i++) {
  const t = performance.now();
  engine.search(query, 5);
  times.push(performance.now() - t);
}
times.sort((a, b) => a - b);
console.log('p50:', times[500].toFixed(2) + 'ms');
console.log('p95:', times[950].toFixed(2) + 'ms');