benchmark comparison

altor-vec vs Weaviate

Feature-rich vector database versus lightweight client-side HNSW.

Weaviate brings database-style workflows, modules, and server infrastructure. altor-vec is far narrower, but that narrowness is exactly why it can fit inside a web bundle.

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	Weaviate
Runtime model	Browser-side WebAssembly index embedded in the product.	Server-side database with API, schema, and cluster concerns.
Bundle size / delivery	~54KB gzipped plus data asset.	No browser bundle for ANN, but substantial infrastructure footprint on the server side.
Query latency	Sub-millisecond local lookup once loaded.	Typically dominated by network and server response time, but appropriate for central search services.
Memory usage	Client memory budget matters because vectors live in the session.	Memory pressure moves to the server where larger corpora are more manageable.
Features	ANN retrieval and serialization only.	Filtering, hybrid search, modules, replication, auth, and broader data workflows.
Dataset sweet spot	Static or moderately sized shipped corpora.	Large shared corpora with write-heavy or backend-centric needs.

Where altor-vec wins

Fits directly in a frontend without provisioning infrastructure.
Works offline and keeps queries on device.
Simple delivery model for docs, widgets, and embedded search.

Where Weaviate wins

Broader features and operational tooling.
Better fit for complex filtering and multi-tenant datasets.
Stronger choice when embeddings and retrieval are part of a larger backend platform.

Honest decision guide

Weaviate wins on backend capability and scale. altor-vec wins when you want vector retrieval to behave like a frontend dependency, not a service to operate.

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 I compare bundle size between altor-vec and Weaviate directly?

Only partially. Weaviate is primarily a backend system, so the real tradeoff is delivery model rather than just kilobytes.

What is the biggest feature gap?

Metadata-rich backend workflows. altor-vec is deliberately not a database.

What is altor-vec's main advantage here?

You can ship it inside the app and get local search without standing up infrastructure.

Get started: npm install altor-vec · GitHub