Short answer
Indexing is what makes a vector database fast. The choice of algorithm shapes its speed, accuracy, and cost, so Pinecone makes that choice for you and adapts it automatically as your data grows. This page defines the algorithms Pinecone uses today, explains the adaptive per-slab model behind them, and covers why Pinecone builds its own algorithms for different parts of the system.
Why Indexing Is Adaptive
A vector database serves very different workloads at once: a few thousand vectors in one namespace, billions in another, some changing every second, some static for months. No single indexing algorithm is optimal across that whole range. A method tuned for a small, fast-changing slab is the wrong choice for a billion-vector slab. The reverse is true too.
Pinecone is serverless and stores data in immutable units called slabs. Because each slab is independent and immutable, Pinecone picks the best algorithm for each one and applies it during background compaction, with no downtime and no work on your side. As Pinecone develops new algorithms, they roll in the same way. The set is not fixed; it improves over time.
The Algorithms
Slab size is the main factor in the choice. Pinecone weighs other factors too, so treat the thresholds below as guidelines, not hard limits.
RaBitQ (Small Slabs)
Used for small slabs, roughly up to 10,000 vectors. Pinecone runs its own implementation of RaBitQ, with modifications. It randomly rotates the vectors and encodes each one as a compact binary code. It builds faster than PQFS, which suits the many small slabs a live index produces. RaBitQ replaces Pinecone's earlier SimHash implementation, known internally as Ananas.
PQFS (Medium Slabs)
Used for medium slabs, roughly 10,000 to 100,000 vectors. PQFS is Pinecone's implementation of fast-scan Product Quantization. It compresses vectors so the index stays accurate and memory-efficient as a slab grows. It is more accurate than RaBitQ but slower to build, which pays off once a slab reaches this size.
IVF With PQFS (Large Slabs)
Used for large slabs, roughly over 100,000 vectors. IVF (Inverted File) clusters the vectors and, at query time, scans only the clusters most likely to hold matches instead of the whole slab. Each cluster is itself a PQFS index. This keeps queries fast as a slab scales toward billions of vectors.
Before any of these apply, new writes land in an in-memory memtable and become queryable within seconds. See Inside Pinecone: Slab Architecture for how data moves from the memtable into slabs.
Why Pinecone Built Its Own Algorithms
A great ANN algorithm is the baseline. A production vector database needs more: instant freshness as data changes, predictable latency at any scale, fast filtered search, and no manual tuning. Filtered search is its own problem: an algorithm that excels on unfiltered benchmarks can degrade sharply when a metadata filter rules out most candidates. Pinecone designed purpose-built algorithms for its serverless slab architecture to deliver all of these together.
Frequently Asked Questions
What Algorithm Does Pinecone Use?
Pinecone uses a set of proprietary algorithms and selects one per slab automatically, based mainly on slab size: RaBitQ for small slabs, PQFS for medium, and IVF with PQFS for large. You never need to select the algorithm or configure how the index is built.
Does Pinecone Use HNSW?
No. Pinecone serverless uses the algorithms described above, selected automatically per slab. HNSW is a specific graph-based algorithm that performs very well on benchmarks. In a dynamic setting, with constant writes and filtered queries, we found that other algorithms work better. Pinecone's earlier pod-based indexes included a p2 pod type built on a variant of the Vamana graph algorithm; p2 is now deprecated, and all new indexes are serverless.
Do I Have to Choose or Tune the Algorithm?
No. Algorithm selection, index building, and upgrades are automatic. Pinecone applies the best algorithm per slab during background compaction, including when it ships improved algorithms, with no reindexing or action from you. For advanced use cases, the optional Dedicated Read Nodes expose a few query-time tuning knobs.
Was this article helpful?
