altor-vec vs typesense

altor-vec vs Typesense — Embedded vs Hosted

A fair comparison between altor-vec and Typesense starts with deployment boundaries, not hype. altor-vec is built for browser-native HNSW retrieval with almost no operational overhead. Typesense assumes a server, service, or native runtime and gives you the controls that environment usually needs. If your product team confuses those boundaries, it will either overbuild for a simple public search surface or underbuild for a private, business-critical retrieval workflow.

Feature comparison table

The table shows why these tools often appear in the same shortlist even though they are not direct drop-in substitutes. altor-vec is strongest when search should be bundled into the application and shipped like any other static asset. Typesense is strongest when search is shared infrastructure with its own mutation path, observability, and security rules. Teams usually get the best outcome when they admit that those are materially different jobs.

Code comparison

altor-vec

import init, { WasmSearchEngine } from 'altor-vec';

await init();
const dim = 4;
const vectors = new Float32Array([
  1, 0, 0, 0,
  0, 1, 0, 0,
  0, 0, 1, 0,
]);
const engine = WasmSearchEngine.from_vectors(vectors, dim, 16, 200, 50);
const hits = JSON.parse(engine.search(new Float32Array([0.95, 0.05, 0, 0]), 3));

Typesense

import Typesense from 'typesense';

const client = new Typesense.Client({ nodes: [{ host: 'localhost', port: 8108, protocol: 'http' }], apiKey: 'xyz' });
const result = await client.collections('docs').documents().search({ q: 'browser vector search', query_by: 'title,body', vector_query: 'embedding:([0.12,0.44,0.31,0.09], k:3)' });

The syntax difference mirrors the architecture. With altor-vec, you initialize WASM, create or load a local index, and search with a Float32Array. With Typesense, you usually authenticate to a service or rely on a backend process, then route your query through that environment. That adds network or runtime boundaries, but it also enables central governance and shared datasets. The “better” option depends on whether your search feature is fundamentally a frontend capability or a backend platform concern.

When to choose each

Choose altor-vec when:

• You want to eliminate backend infrastructure entirely — no server to provision, no Docker container to manage, no Typesense Cloud bill — and your content is static enough to rebuild the search index on each deployment.
• Your search use case is purely semantic: users describe what they are looking for in natural language and you want the most conceptually similar results, without needing typo correction or exact-keyword ranking.
• You are building a documentation site, personal knowledge base, or portfolio where zero-ops search that works offline and costs nothing per query is the ideal outcome.

Choose Typesense when:

• You need production-grade typo-tolerant keyword search with facets, geo-filtering, or dynamic sorting that must work in real time across a corpus that changes frequently and cannot be rebuilt on every deploy.
• Your application has multiple users writing to and querying the same shared index simultaneously — Typesense handles concurrent writes safely via its REST API, which altor-vec's static-file model cannot support.
• You want a batteries-included search platform with InstantSearch UI components, a management dashboard, and an official cloud offering, and you are willing to operate or pay for the server in exchange for that richness.

A hybrid model is common and healthy. Many teams keep browser-local semantic search for public docs, changelogs, release notes, or lightweight catalogs while using Typesense for protected corpora, shared AI services, or complex operational search. That split respects the strengths of both systems instead of forcing everything into one stack just for conceptual purity.

Operational notes

• Index updates: client-side indexes are best when updates happen on deploys or controlled sync jobs.
• Observability: backend systems centralize logs naturally; browser search needs deliberate product instrumentation.
• Security boundary: if the browser should not know the data, browser-local search is not the source of truth.
• Cost model: local search shifts cost into build-time assets and client compute, while backend systems shift cost into infrastructure and query volume.

Another practical difference is ownership. Frontend teams can usually ship altor-vec with existing static deployment infrastructure. Typesense often pulls search into platform, DevOps, or backend ownership. That is not a downside when the product genuinely needs central control, but it is unnecessary drag when all you wanted was better semantic retrieval over public content.

Migration guide: Typesense to altor-vec

Migrating from Typesense to altor-vec is straightforward when your data is public and static. Export your documents from Typesense using the JSONL export endpoint, run them through an embedding pipeline (e.g., transformers.js pipeline locally, or any embedding API at build time), then build the binary HNSW index and host it on your CDN. Replace the Typesense client call in your UI with the pattern below. Your server can be decommissioned once the index file is live.

// Before (Typesense — requires live server)
const results = await client.collections('docs').documents().search({
  q: userQuery, query_by: 'title,body'
});

// After (altor-vec — fully browser-local)
import init, { WasmSearchEngine } from 'altor-vec';
await init();
const res = await fetch('/search-index.bin');
const buf = await res.arrayBuffer();
const engine = WasmSearchEngine.from_bytes(new Uint8Array(buf));
const hits = JSON.parse(engine.search(queryEmbedding, 10));

Bottom line

Use altor-vec when semantic retrieval belongs inside the interface and the browser is allowed to hold the index. Use Typesense when search is a centralized system with private data, fast-changing writes, or operational requirements that the browser should not carry. That is the honest comparison axis, and it is the one that usually leads to the right architecture.