Add a VectorDBBench client for Infino (vector search)

[muralikpbhat]

What

Adds a VectorDBBench client for Infino, an object-storage-native retrieval engine with a Python binding (the infino package). This PR covers vector search; FTS is a planned follow-on.

Search runs over a local loopback server rather than the embedded engine — see "Why a loopback server" below. Requires infino>=0.5.10 (the first published release that ships the infino-bench-serve entry point).

Why a loopback server (memory under multiprocessing)

MultiProcessingSearchRunner forks one client per concurrency slot, and any embedded vector engine gets loaded once per worker — so its resident memory multiplies with concurrency and exhausts the host on larger datasets (this is a general property of embedded clients under the MP runner, not specific to Infino). Infino's graph + quantized planes are large enough that a high-concurrency search on a 10M-scale corpus can OOM the box.

Serve mode removes the multiplication: the client spawns one infino-bench-serve process (bound to 127.0.0.1 only) and each search worker is a thin TCP client, so resident memory stays flat regardless of concurrency. The build (load + optimize) still runs on the embedded engine; only search is served over the socket.

• The server projects the dataset id column and returns it directly, so there is no client-side id map to build, persist, or reload.
• The bind address is loopback-only — the server is a benchmark helper (single host, single table; no auth/TLS/durability), not a network service.

Client

• InfinoConfig / InfinoIndexConfig — connection tuning (catalog path, disk-cache budget/dir, object-store options) and the vector case config (cosine / L2 / inner-product metric map).
• search_mode (default hnsw_ivf) — the serving path, bridged to the engine's vector.search_mode config key rather than the binding API (so nothing goes vestigial if an engine default changes). hnsw_ivf serves a resident HNSW graph over the quantized vectors (with automatic IVF fallback); ivf serves the reclaimable IVF scan.
• ef (default 0) — a serve-time HNSW beam, bridged to vector.hnsw_ef_search. 0 serves each query at the graph's stamped k→ef curve; a positive value fixes the beam. See "Tracing the recall/QPS curve" below.
• Batched inserts — insert_embeddings buffers fed rows and commits them as one large append at a threshold (flushing any remainder when the load scope exits), so a load commits a handful of files regardless of the harness batch size instead of one file per fed batch. Insert speed is independent of NUM_PER_BATCH; the served index is unchanged.
• db_label — plumbed into the result series name, matching the other backends.
• Cosine cases are normalized (need_normalize_cosine). Vector-only / NonFilter.

Tracing the recall/QPS curve

Because ef is a serve-time beam, the recall/QPS curve is traced build once, sweep at serve — the same one-ingest / serve-many shape as an HNSW engine's ef_search, so no re-ingest per point:

1. Ingest + build once (--drop-old).
2. Re-run search-only per beam (--skip-drop-old --skip-load), varying --ef over e.g. 112 128 192 256 384 512 768 1024 2048 — a spread of operating points, densest near the top.

A plain run with no --ef (ef=0) serves at the graph's stamped k→ef curve — a single high-recall operating point (recall@100 ≈ 0.997 on Cohere-1M) — so infino produces a strong default point even without a sweep.

Registration

DB.Infino enum + init_cls / config_cls / case_config_cls; the Infino CLI command; a leaderboard color; and an infino optional-dependency extra (infino>=0.5.10).

Testing

• Unit tests: search_mode / ef validation, the config.yaml bridging, and insert-buffering (every fed row persisted across both the threshold flush and the final flush of a sub-threshold remainder).
• End-to-end: insert_embeddings → search_embedding round-trip (nearest-neighbor identity), plus a full Cohere-1M (768-dim) build-once ef sweep tracing the recall/QPS curve over the loopback server.

Notes

• The client only adds files and small registration hooks; no changes to shared runners or on-disk formats.
• search_mode/ef are bridged through the engine config file because connect() currently exposes no equivalent keyword; the client writes a per-run config and points XDG_CONFIG_HOME at it before connecting.
• Because the server is loopback-only, a submission is single-box (client + server on one host). A follow-up will expose search_mode/ef as run-test UI inputs (frontend/config/dbCaseConfigs.py); this PR keeps the surface to the client and its registration.

[sre-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: muralikpbhat
To complete the pull request process, please assign xuanyang-cn after the PR has been reviewed.
You can assign the PR to them by writing /assign @xuanyang-cn in a comment when ready.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment