Infino's self-driving vector engine

Aug 7, 2026 · engineering

You write a table. Infino builds the vector index — and tunes it to your data. No n_cent, no nprobe, no rerank_mult, no sweeps. On Cohere-10M, that's 0.99 recall@10 — with zero knobs touched.

Most vector databases make you hand-tune dials such as n_cent, nprobe, ef_search, or rerank depth — and wish you luck. Get them wrong and you burn compute or silently ship poor recall, and the "right" values shift with scale and data.

The dials that run your recall bill

• n_cent — how finely to partition the index
• nprobe — how many partitions to actually search
• rerank multiplier — how many candidates to re-score exactly

Set them too conservative and you burn compute chasing recall you didn't need. Too aggressive and you silently ship 0.6 recall to users who expected 0.99. And there's no universal right answer: the sweet spot moves with corpus size, embedding distribution, even your query mix. Perfect at 1M is wrong at 100M. Perfect for clean product vectors, broken for messy multilingual text.

So teams run sweeps, hard-code a compromise, and re-tune every time the data grows. Tuning your ANN index becomes a standing job — a tax on every vector workload.

Infino's answer: write a table, invert it in the background

Infino treats those dials as the engine's job, not yours — and the architecture is built for it.

You write to Infino like a normal table: rows, columns, your vectors sitting next to your metadata. Ingest is cheap and append-only — no index to pre-build, no reindex window, no write stalls.

Then, in the background, Infino inverts that row-ordered data into a globally distance-aligned layout — vectors reorganized by similarity across the entire corpus, so a query reads only the neighborhood that matters.

That background pass is where the tuning happens. As it builds the global structure, Infino measures your actual data — how vectors cluster, how well the coarse code predicts the true nearest neighbor — and stamps a serving plan: partition count, probe width, and rerank budget calibrated to hit your recall target at the lowest cost. At query time it adapts again: probing narrow when the answer concentrates in one neighborhood, wider when it doesn't, and keeping the rerank budget honest as it widens.

How we measured it

On Cohere-10M (10M × 768-d embeddings, a standard vector benchmark), Infino's default adaptive serving — no manual n_cent, nprobe, or rerank_mult, nothing tuned by hand — returns recall@10 ≈ 0.99. The engine calibrated the probe width to the data and found that a narrow search already clears the bar — so it hits that recall without over-probing, spending compute only where it actually helps.

That's the point: the same engine would probe wider on a harder corpus where a narrow search wouldn't clear the bar — because the width is stamped from the data, not from a config you guessed.

What "self-driving" actually means

That's the difference between a database that's easier to tune and one that tunes itself. Infino owns the write path, the index, and the cost/recall trade-off end to end — so you get row-database-simple writes and expert-tuned ANN reads, and spend compute only where recall actually needs it.

And this is just the engine. Infino's serverless offering takes it further — capacity, tiering, and scaling automated end to end.