Squeeze 10M Vector Search into 2GB RAM: A faiss 1.7.4 Playbook
Ten-million-scale vector search doesn't require a commercial database or a large-RAM box; a single 16GB node suffices if you pick the right faiss version and compress properly. The trade-off is precision: 92.3% recall@10 is fine for many production use cases, but the article's numbers give a concrete target to tune from if your recall bar is higher.
Running vector search at the 10-million scale on a 16GB node requires more than just loading float vectors. Uncompressed, 10M 768-dim float32 vectors take roughly 3GB, and the accompanying HNSW index adds 3–5× that, blowing past 12GB. The article's fix is a specific stack: faiss 1.7.4, product quantization (PQ) with m=12 and nbits=8, and an IVF index with nlist set to the square root of the vector count.
Measured results on a 16GB server: vector memory drops from 3GB to 10MB (1 byte per vector), total index memory falls from 12GB to 2GB, and recall@10 settles at 92.3% versus 99.5% uncompressed. The article also walks through the failure modes: training samples below 100× the subspace count drive recall under 65%, and forgetting to disable GPU causes OOM. It recommends pinning faiss to 1.7.4, since 1.7.5 adds no compression features and has binding issues.
Pinning to faiss 1.7.4 over 1.7.5 — despite the newer version adding nothing relevant — suggests that Python binding stability drives production adoption more than feature velocity.
Losing only 7.2 percentage points of recall@10 at a 3000:1 compression ratio shows PQ's efficiency for approximate retrieval, but the article never addresses high-recall requirements, so this path isn't a blanket answer.
The nlist square-root rule is a heuristic that trades precision for speed; it's simple to apply, but real workloads with skewed vector distributions may need a different split.