benchmark comparison

altor-vec vs Server-Side Vector Search

When local browser retrieval wins and when server-side retrieval clearly wins.

This is the umbrella tradeoff behind every individual comparison page. Browser vector search and server vector search are both useful, but they optimize different things: one optimizes delivery and local UX, the other optimizes centralized control and scale.

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	Server-Side Vector Search
Runtime model	Index runs in the browser session next to the UI.	Index runs on a server, managed service, or database cluster.
Bundle size / delivery	You ship the library and corpus to the client.	You ship little or nothing to the client, but every query traverses the network.
Query latency	Best-case interactive latency because the search is local.	Higher floor because network is part of every query, but better for central shared corpora.
Memory usage	Client pays the memory cost.	Server pays the memory and storage cost.
Features	Great for offline, privacy, and embedded UX; weak for centralized operations.	Great for writes, ACLs, filtering, observability, and shared large datasets.
Dataset sweet spot	Safe-to-ship, moderate-size, mostly static corpora.	Private, massive, multi-user, or fast-changing corpora.

Where altor-vec wins

Offline and low-latency UX.
Zero per-query API dependency.
Simple architecture for frontend-owned search experiences.

Where Server-Side Vector Search wins

Large mutable datasets.
Access control and backend integration.
Centralized logging, scaling, and team operations.

Honest decision guide

Browser search wins when retrieval is part of the interface itself. Server search wins when retrieval is part of the infrastructure. Most teams should choose based on that boundary first, not on raw ANN marketing claims.

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

Can browser search replace server search completely?

Only for the subset of use cases where the corpus is safe to ship and moderate in size.

What is the biggest advantage of server-side search?

Control: private data, writes, filtering, observability, and shared infrastructure.

What is the biggest advantage of browser-side search?

Local latency and product simplicity. The UI can search instantly without asking another service for every interaction.

Get started: npm install altor-vec · GitHub