altor-vec vs meilisearch

altor-vec vs Meilisearch — Browser vs Backend Search

A fair comparison between altor-vec and Meilisearch starts with deployment boundaries, not hype. altor-vec is built for browser-native HNSW retrieval with almost no operational overhead. Meilisearch 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. Meilisearch 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));

Meilisearch

import { MeiliSearch } from 'meilisearch';

const client = new MeiliSearch({ host: 'http://127.0.0.1:7700', apiKey: 'masterKey' });
const index = client.index('docs');
const result = await index.search('refund policy', { limit: 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 Meilisearch, 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: Choose altor-vec when semantic retrieval over a public corpus is the core need.

Choose Meilisearch: Choose Meilisearch when typo tolerance, fast writes, and backend filters matter more.

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 Meilisearch 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. Meilisearch 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.

When to choose each

Choose altor-vec when:

• Your search surface is public-facing and semantic — users querying by meaning, not exact keywords
• No server infrastructure budget exists and search must run as a static asset
• Privacy matters: query text must never leave the browser

Choose Meilisearch when:

• Typo tolerance is a core requirement — users misspell, and you must still return correct results
• Your index changes frequently with real-time writes from content editors or APIs
• You need fine-grained filtering (by category, date range, author) alongside text search

Technical architecture comparison

altor-vec and Meilisearch are built on fundamentally different architectures. altor-vec is a WebAssembly binary shipped as an npm package. The index lives in browser memory, loaded from a static JSON file at page load. There is no network request per search — every query runs in the JavaScript runtime in under 5ms for typical doc sets.

Meilisearch is a Rust binary running as a server process. Every search is an HTTP request from the client to the Meilisearch instance. The server handles ranking, typo correction, filtering, and faceting with a full inverted index on disk. This gives Meilisearch its powerful text-search capabilities, but it requires server deployment, health monitoring, and network reliability for each query.

The practical implication: altor-vec moves search responsibility to the frontend team and eliminates backend dependency. Meilisearch moves search to a backend service with all the DevOps overhead that entails — but also gives you centralized control, real-time indexing, and battle-tested keyword ranking.

Migration guide

If you are currently using Meilisearch for documentation or content search and want to move to altor-vec to eliminate server costs:

# 1. Export your Meilisearch documents
# GET /indexes/docs/documents → save as documents.json

# 2. Generate embeddings at build time
import { pipeline } from '@xenova/transformers';
const embedder = await pipeline('feature-extraction', 'Xenova/all-MiniLM-L6-v2');
const docs = JSON.parse(fs.readFileSync('documents.json'));
const vectors = new Float32Array(docs.length * 384);
for (const [i, doc] of docs.entries()) {
  const output = await embedder(doc.content, { pooling: 'mean', normalize: true });
  vectors.set(output.data, i * 384);
}

# 3. Build altor-vec index and save to public/
import init, { WasmSearchEngine } from 'altor-vec';
await init();
const engine = WasmSearchEngine.from_vectors(vectors, 384, 16, 200, 50);
fs.writeFileSync('public/search-index.json', engine.to_json());

The tradeoff: no more server to manage, but you lose real-time indexing (index rebuilds on deploy), typo tolerance, and faceted filtering.

Bottom line

Use altor-vec when semantic retrieval belongs inside the interface and the browser is allowed to hold the index. Use Meilisearch 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.