[FEA] Add Pluggable Backend Interface to cuvs-bench for Multi-VDB Benchmarking

Feature Request: Add Pluggable Backend Interface to cuvs-bench for Multi-VDB Benchmarking

Problem Statement

Currently, cuvs-bench is tightly coupled to C++ Google Benchmark executables via subprocess calls. This limits benchmarking to:

• Only C++ executables that conform to a specific CLI interface
• Local file-based indexes (no network VDBs)
• Hard-coded orchestration logic in runners.py

Impact: Users cannot compare cuVS against industry-standard vector databases (Milvus, Qdrant, Pinecone, Elasticsearch) or benchmark Python-native libraries (hnswlib, faiss-python) without writing C++ wrappers.

Proposed Solution

Introduce a plugin architecture with an abstract BenchmarkBackend interface:

class BenchmarkBackend(ABC):
    def build(self, dataset, build_params, index_path) -> BuildResult
    def search(self, dataset, search_params, k, batch_size) -> SearchResult
    def initialize() / cleanup()  # Lifecycle management

For now we can focus on the below backend types

Three Backend Types:

1. C++ Backend (existing): Wraps current subprocess logic - 100% backward compatible
2. Python Backend: Direct library calls (e.g., hnswlib, faiss-python) - no compilation needed
3. Network Backend: VDB APIs (Milvus, Qdrant, etc.) - connection management, clustering

Example Use Cases

Before (Not Possible)

# Cannot benchmark Milvus
❌ No way to test network-based VDBs

# Cannot benchmark Python bindings without C++ wrapper
❌ Requires writing C++ code + CMake

After (Enabled)

# Compare cuVS against Milvus
python -m cuvs_bench.run \
  --algorithms cuvs_ivf_flat,milvus_ivf_flat \
  --build --search

# Benchmark Python libraries directly
python -m cuvs_bench.run \
  --algorithms hnswlib_python \
  --build --search

Benefits

1. Backward Compatible: Existing C++ benchmarks work unchanged
2. Industry Comparison: Benchmark cuVS vs. Milvus, Qdrant, Pinecone on same hardware/dataset
3. Lower Barrier: Python developers can contribute without C++/CMake knowledge

Implementation Plan

• Phase 1: Add plugin interface + registry
• Phase 2: Wrap existing C++ backend (backward compat)
• Phase 3: Add Python in-process backend
• Phase 4: Add network VDB backend (Milvus example)
• Phase 5: Documentation

Start by reading cuvs-bench's runners.py and the cuvs_bench.run entry point to understand the existing subprocess orchestration and CLI contract. Map how the current C++ benchmark path would fit the proposed interface before considering Python and network backends. Done means existing C++ benchmarks remain compatible and the phased plugin architecture has clear lifecycle and registry behavior.