altor-vec vs qdrant
altor-vec vs Qdrant — Browser WASM vs Rust Vector Database
Qdrant is a high-performance vector database written in Rust, designed for server-side retrieval with payload filtering and production-grade reliability. altor-vec is a 54KB WASM library that runs HNSW vector search entirely in the browser. Both use HNSW indexing — but they serve fundamentally different deployment contexts.
npm install altor-vec — works in the browser immediately. No Qdrant server, no Docker, no config.Feature comparison
| Capability | altor-vec | Qdrant |
|---|---|---|
| Indexing algorithm | HNSW (WASM) | HNSW (Rust) |
| Deployment | Browser (client-side) | Server (Docker, Kubernetes, Qdrant Cloud) |
| Network required | No — runs offline | Yes — HTTP/gRPC to Qdrant server |
| Query latency | Sub-millisecond (no network) | 1-10ms + network round-trip |
| Bundle size | 54KB gzipped | Full server binary |
| Payload filtering | Basic post-search filter | Rich structured filtering at index time |
| Max vectors | ~100K (browser memory) | Billions (distributed) |
| JavaScript support | Native (WASM) | Node.js client (not browser) |
| Privacy | Data stays in browser | Data on your server |
| Cost | Zero API/infra cost | Self-hosted or Qdrant Cloud pricing |
Code comparison
altor-vec (browser, no server)
import init, { WasmSearchEngine } from 'altor-vec';
await init();
const engine = WasmSearchEngine.from_vectors(embeddedVectors, 384, 16, 200, 50);
const hits = JSON.parse(engine.search(queryEmbedding, 5));
// Results in <1ms, no network
Qdrant (Node.js, server required)
import { QdrantClient } from '@qdrant/js-client-rest';
const client = new QdrantClient({ url: 'http://localhost:6333' });
const results = await client.search('my_collection', {
vector: queryEmbedding,
limit: 5,
filter: { must: [{ key: 'category', match: { value: 'docs' } }] },
});
Both use HNSW under the hood, but the deployment model is completely different. altor-vec bundles the index as a WASM asset that ships with your frontend. Qdrant runs as a persistent service that your application calls over HTTP or gRPC. For search that needs to work offline, stay in the browser, or avoid backend infrastructure costs, altor-vec is the right architecture. For search that needs to be shared across services, requires complex filtering, or must handle continuous writes, Qdrant fits better.
The HNSW connection
Both altor-vec and Qdrant use HNSW (Hierarchical Navigable Small World) indexing, which is why they appear together in searches for "best vector search library." HNSW gives near-perfect recall with sub-linear query time. The difference is where the graph lives: in your browser's WASM runtime with altor-vec, or in a Rust process on your server with Qdrant.
When to choose each
Choose altor-vec when: your search is a frontend feature, data is public or device-local, you want offline capability, or you need zero-cost vector search without infrastructure management.
Choose Qdrant when: you need server-side vector retrieval, rich payload filtering (category, date range, metadata), billions of vectors, or search as shared infrastructure across multiple services.
npm install altor-vec — HNSW in your browser, sub-millisecond queries, 54KB. No Qdrant server needed.