PrairieFire: Igniting High-Throughput Updates in Large-Scale Approximate Nearest Neighbor Search: what it means for business leaders

RedNote's PrairieFire makes a billion-vector SSD-resident nearest-neighbour index absorb inserts and deletes three to 35 times faster than the best prior systems while serving searches, so an index can track hourly embedding retraining without full rebuilds.

1. What the method is

PrairieFire is an approximate nearest neighbour search system for billion-scale embedding collections stored on NVMe SSD arrays, built so that the index can take inserts and deletes at the same rate it takes queries. The advance is a three-level partition index in which every vector partition on SSD carries a small in-memory buffer, updates are held in that buffer and flushed as one batch, imbalanced partitions are repaired by reclustering their neighbourhood on a GPU rather than relocating vectors one at a time, and centroid changes cascade upward so routing stays accurate. A granularity-decoupled locking scheme lets searches, inserts, deletes and rebuilds run concurrently. Against Greator, OdinANN and SPFresh on 100-million and one-billion vector workloads the authors report three to 35 times the update throughput, three to five times the search throughput, and 1.5 to 8.7 times the hardware efficiency. It has run in RedNote production for two months.

2. Why the method was developed

Our recommendation, search and retrieval-augmented generation stacks all sit on vector indexes whose contents change constantly: items arrive and retire, and embedding models are retrained hourly or faster, which changes every vector. Refreshing a 100-million-vector index every hour needs about 30,000 updates per second, which earlier SSD-based systems could not approach. OdinANN, a graph index, spends four to seven milliseconds of multi-hop SSD reads per insert and reaches two to three thousand updates per second. SPFresh, a partition index, reaches about twelve thousand on 64 cores and would need 128 to 256 cores for the target, because every insert rewrites SSD pages and every split or merge relocates vectors individually. The authors show the bottleneck is CPU cycles, not disk: ten Gen5 SSDs offering 120 GB/s saw under 1 GB/s used. Simply buffering updates in SPFresh fails too, since its very fine partitions and eight-way replicated placement bloat memory and defeat batching.

3. Who should care

This touches our infrastructure and platform teams first, since they own the vector serving tier and decide whether freshness comes from periodic full rebuilds or from streaming updates. Our applied ML teams that retrain embedding models care because the paper's design lets a retrain be absorbed as a stream of deletes and re-inserts instead of waiting on a rebuild window, which changes how often they can ship. Capacity planning and finance should note the hardware shape: the gains depend on a server with GPUs, a dozen-channel memory bus and an array of Gen5 SSDs with direct GPU-to-SSD I/O, so this is a server design decision rather than a software swap. If we buy rather than build, procurement and architecture should ask any vector database vendor for update throughput measured under concurrent search, since that is the number this paper shows most products cannot sustain at scale.

4. How the method works

Vectors live in disjoint partitions on SSD, each about one to two percent of the dataset in count, with contiguous pages of 16 KB and a buffer of up to eight vectors in host memory. Partition centroids sit in memory, and routing centroids over those sit on the GPUs, with a host-side shadow copy. An insert routes through a batched GPU distance kernel and the in-memory level, appends to one partition's buffer and records the vector-to-partition mapping in a hash map; a delete pops the vector from the buffer or marks it as a tombstone. When a buffer fills or tombstones accumulate, a flush merges buffer and valid SSD vectors and rewrites the pages once. An oversized or undersized partition triggers reclustering of up to 64 nearby partitions on the GPU with a fused k-means kernel that finishes in under five milliseconds, and the refreshed centroids propagate upward. Per-cluster locks with versions, slot-hashed vector locks and ordered acquisition keep searches, updates and rebuilds consistent without blocking each other.

5. How it was evaluated

The authors tested on their production server shape: a 64-core AMD EPYC Genoa, twelve-channel DDR5 memory, ten 2 TB PCIe Gen5 NVMe SSDs and two NVIDIA RTX Pro 5000 Blackwell GPUs. Three standard dynamic workloads were used: Workload A deletes and re-inserts 100 million uniform SIFT vectors, Workload B does the same on 100 million skewed SPACEV vectors, and Workload C starts from 900 million SIFT vectors and streams the remaining 100 million as updates. Baselines were Greator, OdinANN and SPFresh, with SPFresh adapted to a multi-SSD layout, and the GPU-based SVFusion for a separate comparison. Threads were allocated to give each system a one-to-one update-to-search ratio; PrairieFire used 16 foreground and two background update threads and 46 search threads. Metrics were update and search throughput, tail latency, recall at ten and memory. The text we have is truncated before the sensitivity, hardware-efficiency, GPU and production sections, so those details rest on the abstract and introduction.

6. How it performed

At 100 million vectors PrairieFire delivered three to 35 times the update throughput and three to five times the search throughput of the baselines on both uniform and skewed data, with lower tail latency, equal or better recall and similar memory. Each update took 0.4 milliseconds, and two background threads kept up with 40,000 foreground updates per second, where SPFresh managed ten to twelve thousand with 48 threads. At one billion vectors both update and search throughput held at 36,000 to 39,000 per second, three times the search and up to 27 times the update rate of the baselines, with higher recall. The abstract reports 1.5 to 8.7 times the hardware efficiency and, after two months at RedNote, a 95 percent drop in rebuild frequency and better click-through rate, without magnitudes we can see. The limits are real: the gains need the paper's specific GPU-plus-SSD server, every result comes from the vendor's own team, and no open-source release is mentioned in the text we have. If we run SSD-based vector search with hourly embedding refreshes, pilot this design on one index; otherwise watch. (Source: arXiv 2610.23232, 2026)