VectorChord (Vector Index)

VectorChord adds a high‑performance vector index to Postgres that works with the pgvector vector data type. It is independent of pgvector’s HNSW/IVF indexes and targets large‑scale, low‑latency vector search.

• Index type: IVF‑RaBitQ (vchordq)
• Optimized for: large vector volumes, lower query latencies, higher‑dimension embeddings
• Compatible with: vector column type from the pgvector extension

Use cases

• RAG at scale: Billions of vectors, frequent top‑k lookups with tight latency budgets.
• High‑dimensional embeddings: Multimodal or LLM‑generated vectors with larger dimensions than typical ANN setups.
• Low‑latency APIs: Recommendation, personalization, and semantic search where P95/P99 latency matters.

When to choose VectorChord

• Your pgvector HNSW/IVF indexes struggle with high dimensions or large data volumes.
• You need lower query latency for top‑k searches at high throughput.
• You want to stay on the vector type while changing only the index implementation.

Quick start

1) Install pgvector (for the vector type) and the VectorChord package. 2) Create a table with a vector column and load embeddings. 3) Build a VectorChord index and run ANN queries.

Example

-- Table with vector embeddings
CREATE TABLE items (
  id bigint primary key,
  embedding vector(1024)
);

-- Create a VectorChord index (IVF‑RaBitQ)
CREATE INDEX items_embedding_vchordq
  ON items
  USING vchordq (embedding);

-- Example query (distance operator depends on your metric)
-- For illustration, using a placeholder parameter :query_vec
SELECT id
FROM items
ORDER BY embedding <-> :query_vec
LIMIT 10;

Best practices

• Choose a consistent distance metric; ensure it matches query operators.
• Batch index builds during off‑peak hours; monitor memory and I/O.
• Periodically reindex if the data distribution or scale changes significantly.

See also

• Installing VectorChord
• Release notes