VectorChord
A high-performance PostgreSQL extension for vector similarity search, positioned as a **drop-in replacement for pgvector** with order-of-magnitude speedups at billion scale. Built by **TensorChord** (creators of pgvecto.rs). Uses a proprietary IVF + **RaBitQ** index — branded **VChord** — that is disk-based and SIMD-optimized instead of pgvector's memory-bound HNSW, cutting RAM requirements ~**70%** while keeping query speed.
Summary
A high-performance PostgreSQL extension for vector similarity search, positioned as a **drop-in replacement for pgvector** with order-of-magnitude speedups at billion scale. Built by **TensorChord** (creators of pgvecto.rs). Uses a proprietary IVF + **RaBitQ** index — branded **VChord** — that is disk-based and SIMD-optimized instead of pgvector's memory-bound HNSW, cutting RAM requirements ~**70%** while keeping query speed.
VectorChord is the choice when a team has PostgreSQL operational expertise and wants to lift the vector-search ceiling without migrating to Pinecone, Qdrant, or Milvus. Vectors stay inside PostgreSQL — same transactions, same joins, same ACID guarantees. v1.1 (Feb 2026) makes a 1B-vector index practical on a 16-vCPU machine. Earth Genome runs **3.2B vectors** for environmental monitoring on this stack.
- "Drop-in replacement" is true at the SQL/data-type layer but the index type changes — existing pgvector tables must rebuild indexes to get the speedup. Schema-compatible, not index-compatible.
- The 70% RAM cut vs HNSW is real but it's a disk-based index — under-provisioned IOPS makes it look slow. Use NVMe, not generic gp3 EBS, at billion scale.
- 100× faster index build is on billion-scale, not on 100K-vector small workloads — at small scale pgvector's HNSW is still fast enough that the operational risk of switching isn't justified.
- VectorChord-BM25 is a separate extension — keyword + vector hybrid search isn't out-of-the-box.
- Apache-style license but the project is governed by TensorChord (commercial entity); single-vendor governance risk applies the same way it would for any extension under a startup's stewardship.
Performance posture: 100M vectors indexed in 20 minutes (16 vCPU); 1B vectors indexed in 1.8 hours (AWS i7ie.6xlarge). 40 ms P99 at 95% recall on 1B vectors. 3× QPS vs pgvector at the same recall on LAION 5M.
scoped_toVector Indexing on Object Storage — billion-scale vector index inside PostgreSQLcompetes_withQdrant — alternative billion-scale vector pathcompetes_withMilvus — alternative billion-scale vector pathcompetes_withWeaviate — alternative billion-scale vector pathsolvesCold Scan Latency — disk-based IVF with cache-friendly traversal
Definition
A high-performance PostgreSQL extension for vector similarity search, positioned as a **drop-in replacement for pgvector** with order-of-magnitude speedups at billion-scale. Built by **TensorChord** (creators of pgvecto.rs), fully wire-compatible with pgvector's data types and SQL syntax. Introduces a proprietary indexing algorithm called **VChord** that combines an Inverted File Index (IVF) with **RaBitQ** — a Product Quantization technique optimized for modern CPU SIMD instructions. Disk-based design instead of pgvector's HNSW (which is memory-bound), cutting RAM requirements by up to **70%** while maintaining query speed. Supports vectors up to 60,000 dimensions with both L2 and cosine operators. v1.1 shipped February 2026.
pgvector's HNSW index is memory-bound — billion-scale vector workloads either spill to disk and lose performance or buy enormous RAM machines. VectorChord's IVF+RaBitQ design lets a single PostgreSQL instance serve a billion vectors on a 16-vCPU box with 192 GB RAM in 1.8 hours of index build time. For teams with PostgreSQL operational expertise, VectorChord lifts the ceiling without forcing a migration to Pinecone, Qdrant, or Milvus — vectors stay inside PostgreSQL transactions, joins, and ACID guarantees.
Billion-scale RAG embedding stores inside an existing PostgreSQL deployment; replacing pgvector at scale without rewriting the data layer; production RAG with strict ACID/transaction requirements; environmental monitoring at planet scale (Earth Genome runs **3.2B vectors**); cost-sensitive deployments wanting to avoid the all-RAM pricing curve.
Recent developments
VectorChord 1.1 — native 4/8-bit vector types and per-index query defaults. Quantized vector types land natively in PostgreSQL, cutting index size and memory footprint for large collections, with tuning defaults now settable per index rather than per session. Per VectorChord blog — 1.1 release.
VectorChord 1.0 (May 2026) claims 100× faster vector indexing than pgvector HNSW; EDB Postgres AI adopted it in Q1 2026. Vendor-published benchmark claim — but the EDB adoption is the stronger signal: a major Postgres distribution shipping VectorChord as its vector engine moves it from extension-ecosystem experiment to distribution-default candidate. Postgres-native vector search now has an internal performance race (pgvector vs VectorChord) on top of the external one against dedicated vector DBs. Per VectorChord 1.0 release and EDB press release.
Releases · tensorchord/VectorChord-bm25. VectorChord-bm25 0.2/0.3 releases with decoupled tokenizer supporting multi-language, custom stopwords, synonyms, and stemmers. Provides BM25 text ranking in PostgreSQL. Per GitHub (tensorchord/VectorChord-bm25) (2025-12-15).
Releases · tensorchord/VectorChord. GitHub releases page showing VectorChord 1.1.1, 1.1.0, 1.0.0 and earlier versions. 1.1 adds rabitq8/rabitq4 types and per-index query defaults. 1.0 delivered 100M vector indexing in 20 minutes. Per GitHub (tensorchord/VectorChord) (2025-09-15).
awesome-vector-databases/details/colbertv2.md at master. VectorChord with MaxSim operators is listed as supporting ColBERTv2 multi-vector embeddings in 2026, alongside Weaviate 1.29+, Qdrant with FastEmbed, Vespa with native ColBERT embedder, and Milvus with Array of Structs. Per GitHub (ever-works/awesome-vector-databases) (2025-05-13).
GitHub. With VectorChord, you can store 400,000 vectors for just , enabling significant savings: 6x more vectors compared to Pinecone's optimized storage and 26x more than pgvector/pgvecto.rs for the same price. Host 100M x 768-dimensional vectors on AWS i4i.xlarge (**Relationships:**47/month), host 1B x 96-dimensional vectors on i7ie.6xlarge (**Relationships:**246/month). Per GitHub (tensorchord/VectorChord) (2024-09-03).
VectorChord is now inside the standard vector-DB benchmark toolchains, not just its own blog posts. EnterpriseDB shipped
vsbt, an open benchmark toolkit comparing pgvector, VectorChord, and GPU-accelerated pgpu on PostgreSQL vector search; separately,zilliztech/VectorDBBench— the widely-used cross-vendor benchmark suite — merged a PR adding native VectorChord support (lists/probes parameters). Independent, engine-neutral tooling adopting VectorChord as a first-class target is a stronger adoption signal than vendor-published numbers. Per GitHub — EnterpriseDB/vsbt and GitHub — zilliztech/VectorDBBench pull requests.ThoughtWorks Technology Radar has assessed VectorChord. ThoughtWorks' Radar describes it as the successor to pgvecto.rs, using IVF + RaBitQ quantization for fast, scalable, accurate vector search with reduced computation — an independent industry-analyst read on the project separate from TensorChord's own claims. Per ThoughtWorks Technology Radar — VectorChord.
The mechanism behind the headline numbers: hierarchical K-means clustering builds the IVF centroids, RaBitQ does a 1-bit scan, and only survivors get full-precision reranking. VChord's index build runs hierarchical K-means to cluster vectors into centroids (the IVF structure), then RaBitQ compresses each 32-bit float vector into a 1-bit binary representation for the initial coarse scan — full-precision distance computation only runs during the reranking phase, on the small shortlist that survives the bitwise pass. That two-phase compress-then-rerank design is why VectorChord can host 400,000 vectors for $1 of infrastructure (26× pgvector's density at the same price), index 100M vectors in 20 minutes, and hit roughly double pgvector's QPS at equivalent recall — those figures already covered elsewhere in this entry are the output of this mechanism, not a separate claim. Per VectorChord (GitHub — tensorchord/VectorChord). Sources: GitHub (tensorchord/VectorChord-bm25) · GitHub (tensorchord/VectorChord) · GitHub (ever-works/awesome-vector-databases) · GitHub (tensorchord/VectorChord)
Connections6
Outbound5
scoped_to1solves1Inbound1
alternative_to1Resources3
Source repository for VectorChord, the IVF+RaBitQ-based PostgreSQL extension. Drop-in pgvector replacement with disk-based indexing for billion-scale workloads on a single PostgreSQL instance.
TensorChord's positioning piece on cost-per-vector economics — frames the "70% RAM cut" claim and the per-dollar-per-vector throughput vs pgvector HNSW.
Companion extension for BM25 keyword search — the hybrid-search story is opt-in, not bundled, so this is what teams need for dense+sparse retrieval inside PostgreSQL.