PrairieFire: Igniting High-Throughput Updates in Large-Scale Approximate Nearest Neighbor Search

What it claims

PrairieFire is an SSD-based ANNS system from East China Normal University, RedNote (Xiaohongshu) and Shanghai Jiao Tong University. It targets about 30K update QPS on one server, where one update is one insert plus one delete. The authors derive that target from refresh rates: rebuilding a 100M-vector index every hour, or a 1B-vector index every 10 hours. The two named baselines miss it badly on 64 CPU cores: OdinANN (graph-based) reaches 2 to 3K QPS and SPFresh (partition-based) about 12K QPS. In production at RedNote, PrairieFire hosts dozens of indexes and cuts index rebuild frequency by over 95%. RedNote's existing search SLA is 5 to 10 ms, served by its SSD-based Helmsman system.

How it works

The diagnosis is that SPFresh updates are CPU-bound, not bandwidth-bound. Foreground inserts do read-modify-write on SSD posting lists for each insertion. Background splits and merges then reassign vectors one at a time. PrairieFire changes both paths:

• Buffered updates. Inserts to the same cluster collect in memory and flush to SSD as a batch.
• Batched local rebuilds. An imbalanced region is reclustered in one pass instead of relocating vectors one by one.
• Coarser partitions, single copy. SPFresh uses centroids numbering 12 to 16% of vectors and writes each vector to up to 8 posting lists. With that layout, even 8 to 16-vector buffers would raise memory 2 to 3x. PrairieFire uses partitions at 1 to 2% of dataset size and stores each vector once.
• Three-level partition index with cascaded updates. Inserts and deletes propagate to upper-level centroids, so centroids keep tracking the data as it drifts.
• Fine-grained concurrency control across inserts, deletes, searches and local rebuilds.
• CPU-GPU-SSD co-design. GPUs handle centroid routing, partition scanning and the clustering work in rebuilds.

Evidence

The fetched text contains the motivation measurements, not the evaluation tables.

All measurements below use SIFT100M with a 1:1 insert/delete mix:

• SPFresh bandwidth. Scaling to 10 PCIe Gen5 SSDs (about 120 GB/s) improves SPFresh update throughput by less than 10%. SPFresh uses under 1 GB/s of that bandwidth.
• SPFresh cores. The authors estimate SPFresh would need 128 to 256 cores to hit 30K QPS, before any cores are reserved for search.
• OdinANN inserts. Each insert searches the SSD-resident graph for its top-100 neighbors. That search costs 4 to 7 ms, up to 80% of insert time, and lock contention limits concurrency further.
• Merge-based graph systems. For FreshDiskANN and Greator, merging 6M vectors into a 60 GB, 100M-vector index costs 32 GB peak memory and 1.5 to 2x search latency.

Limits

• Truncated text. The fetched text stops in Section 3.3. The 3 to 35x update, 3 to 5x search and 1.5 to 8.7x cost figures appear only as abstract-level claims. Their hardware, datasets, recall levels and per-baseline breakdown are not in the text.
• Accuracy. The text says only that accuracy is "comparable to or higher than baselines".
• Design costs. With fewer partitions and no replicas, each query must scan more clusters to keep accuracy. Reclustering also costs more compute than per-vector reassignment, which is why the design relies on GPUs.
• Hardware. A deployment needs GPUs alongside high-bandwidth NVMe arrays.
• Code and licence. The text mentions no code release, licence or usage instructions.