VectorChord 1.1.1 Release Notes

Features

Added 4 new functions:

• dequantize_to_vector(rabitq8)
• dequantize_to_halfvec(rabitq8)
• dequantize_to_vector(rabitq4)
• dequantize_to_halfvec(rabitq4)

These functions convert quantized vectors back into floating-point vectors.

See Quantization Types for docs.

What's Changed

Replaced the quantization algorithm used by:

• quantize_to_rabitq8(vector)
• quantize_to_rabitq8(halfvec)
• quantize_to_rabitq4(vector)
• quantize_to_rabitq4(halfvec)

with a faster implementation for improved performance.

Full Changelog: 1.1.0...1.1.1

VectorChord 1.1.0 Release Notes

Features

VectorChord now provides rabitq8 and rabitq4 types. They are RaBitQ-quantized vectors, internally stored as uint8[] or uint4[] instead of float32[] or float16[], costing less storage. Like other vector types, you can create indexes for them.

CREATE TABLE items (id bigserial PRIMARY KEY, embedding rabitq8(3));
CREATE INDEX ON items USING vchordrq (embedding rabitq8_l2_ops);
INSERT INTO items (embedding) VALUES (quantize_to_rabitq8('[0,0,0]'::vector));
INSERT INTO items (embedding) VALUES (quantize_to_rabitq8('[1,1,1]'::vector));
INSERT INTO items (embedding) VALUES (quantize_to_rabitq8('[2,2,2]'::vector));
--- ...
SELECT id FROM items ORDER BY embedding <-> quantize_to_rabitq8('[0.9,0.9,1.1]'::vector) LIMIT 100;

See Quantization Types for docs.

Search parameters could be configured via index storage parameters since 1.1.0. Search parameters can be bound to the index, so they don't need to be specified in a session or transaction.

CREATE INDEX items_embedding_idx ON items USING vchordrq (embedding vector_l2_ops) WITH (options = $$
build.internal.lists = [1000]
$$, probes = '10');

See Fallback Parameters for docs.

What's Changed

PostgreSQL 13 is now end-of-life and will no longer receive security and bug fixes. VectorChord drops PostgreSQL 13 support as of 1.1.0.

Full Changelog: 1.0.0...1.1.0

VectorChord 1.0 Release Notes

VectorChord 1.0 is here. This release delivers much faster PostgreSQL index builds with IVF + RaBitQ, quicker updates, broader architecture support, and a stack of new features since our first release. It’s a major milestone—production-ready and thoroughly tested.

Highlights

We have dramatically optimized index build speed, now capable of building a 100M-vector dataset in 20 minutes on a 16-vCPU machine while sharply cutting memory usage, making index construction in production far more convenient.

What's changed since 0.5

Performance & scalability

• Lock-contention optimizations in index building
• Faster table sampling in index building
• Hierarchical K-means
• Dimension reduction in K-means
• Parallel compacting in index building
• Prints estimated memory usage in index building

Fixes

• Don't use expensive Rayon fold/reduce
• Freespace recycle in vchordg

Full Changelog: 0.5.3...1.0.0

VectorChord 0.5.3 Release Notes

• Fix build.pin if parallel build is not enabled. #346
• Run tests on x86_64 MacOS. #348
• Build prebuilt packages for PostgreSQL 18. #349

VectorChord 0.5.2 Release Notes

• Add built-in query simpling, for recall evaluation with online queries, see also Query sampling. (#321, #334, #337, #338)
• Fix MVCC violation if either build.rerank_in_table or vchordrq.prefilter is enabled. (#336)
• Fix incorrect order of vchordrq.probes. (#342)

The vchord-postgres image includes pgvector 0.8.1 now. You could update the extension schema by running the following SQL:

ALTER EXTENSION pgvector UPDATE;
ALTER EXTENSION vchord UPDATE;

VectorChord 0.5.1 Release Notes

• A little performance improvement. (#314)
• Fix compilation on x86_64 nix with gcc.arch set. (#316)
• Fix compilation and tests, and add initial simd support, on s390x and powerpc64le, see also s390x. (#318, #323, #324, #326, #325, #327, #328, #329, #330)

Full Changelog: 0.5.0...0.5.1

VectorChord v0.5.0

Two big upgrades, focused and pragmatic.

1) Experimental DiskANN (with RaBitQ) — vchordg (preview)

A new disk-backed graph index that keeps memory low while giving you a DiskANN-style option inside VectorChord.

• When it shines: can be faster than IVF+RaBitQ (vchordrq) on some embeddings (e.g., OpenAI/Cohere) — but not always.
• Caveats: slow build, and insert/delete are weaker than IVF. Dataset-dependent: benchmark before switching.
• Try it:

  CREATE INDEX ON items USING vchordg (embedding vector_l2_ops)
  WITH (options = $$
    m = 64
    ef_construction = 128
  $$);
  
  SET vchordg.ef_search = 128;

• Memory knob: bits = 1 halves index memory vs default bits = 2 (better recall/QPS).

We’re shipping this to give you a one-stop vector search toolbox at VectorChord. Feel free to share any thoughts and questions about it!

2) Recall measurement for IVF+RaBitQ — vchordrq_evaluate_query_recall

Approximate ≠ exact. Now you can quantify how close your results are with vchordrq_evaluate_query_recall. It accepts a query that returns row identifiers (e.g., ctid) and returns a recall score.

SET vchordrq.probes = '100';
SET vchordrq.epsilon = 1.0;

SELECT vchordrq_evaluate_query_recall(query => $$
  SELECT ctid FROM items
  ORDER BY embedding <-> '[3,1,2]'
  LIMIT 10
$$);  -- add ", exact_search => true" for table-scan ground truth

Note: recall evaluation targets vchordrq in 0.5 (not vchordg yet).

Other fixes

We fixed some performance regression problems in this release. User can enjoy better performances with it!

Talk to us

Thanks for building with us. If you have any question or thoughts, open an issue, join our discord or start a Discussion. Your notes guide what we fix first. If VectorChord helped you, drop us a ⭐ on GitHub and hit Watch → Releases.

VectorChord 0.4.3 Release Notes

• use mimalloc on aarch64-linux
• fix compilation with gcc on x86_64
• fix compilation with clang on Windows
• prompt the user to rebuild the index after the upgrade

Full Changelog: 0.4.2...0.4.3

VectorChord 0.4.2 Release Notes

• fix compilation on aarch64 macos
• add support for pgxnclient: you can install VectorChord with pgxnclient install vchord==0.4.2 now

Full Changelog: 0.4.1...0.4.2

VectorChord 0.4.1 Release Notes

• Fix potential precision issue if the dimension of vectors is 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768.

Full Changelog: 0.4.0...0.4.1