vectorchord on Vchord

VectorChord 1.1: Native 4/8 Bit Vector Types and Per-Index Query Defaults

Sat, 14 Feb 2026 00:00:00 +0000

We’re excited to announce the release of VectorChord 1.1 as we kick off the new year of horse.

VectorChord 1.0 was a milestone for Postgres-native vector search: it made large-scale indexing fast enough to feel like iteration, not an outage. In 1.1, we’re building on that foundation with RaBitQ8: A new vector type that delivers 4x storage savings and faster search speeds compared to float32, all with less than 1% recall loss. Paired with RaBitQ4 and more composable query control, VectorChord 1.1 is ready for your most demanding production workloads.

VectorChord 1.0: Developer-First Vector Search on Postgres, 100x Faster Indexing than pgvector

Thu, 04 Dec 2025 00:00:00 +0000

Two years ago, when we published the very first pgvecto.rs blog post, we made a bet: Postgres is the best place to do vector search. Since then we’ve been iterating on that bet — from VBASE with filtered vector search, to longer vector support, to the RaBitQ quantization scheme and disk‑friendly index layouts.

With VectorChord 1.0 we’re moving the needle again. On a 16 vCPU machine, we can now build an index over 100M vectors in under 20 minutes. On the same scale, pgvector needs more than 50 hours. That number sounds impressive, but the point of this release isn’t just to win a benchmark slide. It’s to make your actual development and iteration loop much faster.

VectorChord 0.5: New RaBitQ-empowered DiskANN Index and Continuous Recall Measurement

Fri, 26 Sep 2025 00:00:00 +0000

We’re thrilled to announce the release of VectorChord 0.5! This release marks a significant step forward in our mission to provide more flexible, powerful, and controllable vector search capabilities. In the 0.5 release, we’re introducing two major updates: experimental support for the DiskANN graph index and a new recall measurement tool to monitor the health of your IVF+RaBitQ indexes proactively.

New Index Preview: RaBitQ-empowered DiskANN Index

From day one, VectorChord’s core indexing solution has relied on a powerful combination: the cluster-based IVF algorithm and RaBitQ quantization—what we ship as vchordrq (IVF+RaBitQ). This approach consistently delivers excellent low-latency, high-recall performance across a wide range of use cases and remains our recommended default for most scenarios.

Bringing Search‑Engine Ranking to PostgreSQL with VectorChord‑BM25

Tue, 12 Aug 2025 00:00:00 +0000

Modern applications rely on PostgreSQL for its fully ACID‑compliant, expressive SQL, and rich ecosystem of extensions. The database handles relational workloads exceptionally well, but many projects also need to search for large text collections—product descriptions, support tickets, documentation—and present the most relevant rows first. PostgreSQL’s native tools offer a foundation for this, yet their default ranking logic can leave ideal matches buried under less useful results. VectorChord‑BM25 changes that equation by introducing the BM25 relevance‑scoring algorithm directly into PostgreSQL.

VectorChord 0.4: Faster PostgreSQL Vector Search with Advanced I/O and Prefiltering

Thu, 05 Jun 2025 00:00:00 +0000

We’re excited to announce the release of VectorChord 0.4, a significant update that enhances high-performance vector search within PostgreSQL. We believe this release pushes the boundaries of what’s possible for vector search in PostgreSQL, introducing key architectural improvements designed to lower latency and increase throughput for demanding, real-world workloads.

If you’re working with similarity searches, RAG pipelines, or other AI-driven applications on PostgreSQL, these updates are for you. We’ve focused on two major areas: significantly enhancing I/O for cold queries by leveraging PostgreSQL’s evolving capabilities, and optimizing filtered vector searches.

VectorChord: Cost-Efficient Upload & Search of 400 Million Vectors on AWS

Fri, 30 May 2025 00:00:00 +0000

In this article, we will describe one method for uploading, indexing, and searching a big dataset of vector data in a cost-efficient manner using the real-world LAION-400M dataset and the VectorChord extension in PostgreSQL.

We’re attempting to show you what kind of hardware setup you need to allow you to search through this vast dataset using VectorChord. We want to make sure that you have a good experience with a search that is both accurate and fast.

All-in-one VectorChord Suite: Building Production-Ready RAG Solutions Directly in PostgreSQL

Tue, 29 Apr 2025 00:00:00 +0000

Retrieval-Augmented Generation (RAG) is revolutionizing our interaction with vast datasets and language models. RAG systems offer more precise, contextually aware, and current answers by retrieving pertinent information before generating responses. Nonetheless, constructing robust, scalable, and efficient RAG pipelines poses considerable challenges, particularly for production use.

Many solutions feature complex architectures, using distinct databases for vector search, keyword search, and primary data storage. This commonly results in data synchronization challenges, greater infrastructure complexity, and higher operational costs.

Beyond Text: Unlock OCR-Free RAG in PostgreSQL with Modal & VectorChord

Tue, 15 Apr 2025 00:00:00 +0000

Building effective Retrieval-Augmented Generation (RAG) systems for documents often feels like wrestling with messy, complex pipelines. Especially when dealing with PDFs or scanned images, traditional methods rely heavily on Optical Character Recognition (OCR) and layout analysis. These steps can be slow, error-prone, and often lose crucial visual context like tables, figures, and formatting. But what if you could query documents based on how they look, not just the extracted text?

VectorChord 0.3: Bringing Efficient Multi-Vector Contextual Late Interaction in PostgreSQL

Sun, 13 Apr 2025 00:00:00 +0000

We’re thrilled to announce the release of VectorChord 0.3, a major milestone that significantly boosts the performance and applicability of advanced vector search techniques directly within your Postgres database! Building on our 0.2 release, which brought ARM support and faster indexing, version 0.3 tackles one of the biggest hurdles in modern retrieval: efficient multi-vector search with late interaction.

Beyond Single Vectors: Why Multi-Vector Rocks

For years, vector search primarily represented entire documents or queries as single, dense vectors. While powerful, this approach involves averaging or compressing complex information into one representation, inevitably leading to a loss of nuance. Imagine trying to capture the entire meaning of a detailed technical document in a single sentence – you’d lose specifics!

Vector Search Over PostgreSQL: A Comparative Analysis of Memory and Disk Solutions

Thu, 03 Apr 2025 00:00:00 +0000

Introduction: real-world challenges

Specialized vector databases aren’t always needed. With PostgreSQL extensions like pgvector, pgvectorscale, VectorChord (which evolved from pgvecto.rs)****, you get vector search plus relational power—no extra infrastructure. But adoption isn’t seamless. Here’s what real users say:

The query takes 30 seconds for the first time and 100ms if it’s a repeat query. The problem is very slow IO.

Is it normal to take 3 hours to build the index for 12 million rows with 75 dimension vector?

After 13 hours of building index for 200 million vectors of 75 dimensions each, I have noticed a heavy memory usage at 100GB/124GB at 30% of building index, and server will eventually crash.

We’re hitting some challenges, particularly around need for frequent index updates, throughput constraints, lack of parallel index scans and no built-in quantization.

VectorChord-BM25: Introducing pg_tokenizer—A Standalone, Multilingual Tokenizer for Advanced Search

Wed, 02 Apr 2025 00:00:00 +0000

We’re excited to announce the release of VectorChord-BM25 version 0.2, our PostgreSQL extension designed to bring advanced BM25-based full-text search ranking capabilities directly into your database!

VectorChord-BM25 allows you to leverage the power of the BM25 algorithm, a standard in information retrieval, without needing external search engines. This release marks a significant step forward, focusing heavily on enhancing the core text processing component: tokenization, unlocking greater flexibility and significantly improved multilingual support.

Hybrid search with Postgres Native BM25 and VectorChord

Thu, 13 Mar 2025 00:00:00 +0000

In the era of RAG (Retrieval-Augmented Generation), efficiently retrieving relevant data from vast datasets is crucial for businesses and developers. Traditional keyword-based retrieval methods, such as those utilizing BM25 as a scoring mechanism, excel in ranking documents based on term frequency and exact keyword matches. This makes them highly effective for structured queries and keyword-heavy content. However, they struggle with understanding synonyms, contextual nuances, and semantic intent. Conversely, vector-based retrieval captures deep semantic meaning, enabling better generalization across varied queries but sometimes sacrificing precision in exact keyword matches. Hybrid Search bridges this gap by combining BM25’s precision with vector search’s contextual understanding, delivering faster, more accurate, and semantically aware results.

Vector Search at 10,000 QPS in PostgreSQL with VectorChord

Thu, 27 Feb 2025 00:00:00 +0000

VectorChord is a PostgreSQL extension designed for scalable, high-performance, and disk-efficient vector similarity search, and serves as the successor to pgvecto.rs. In our previous blog post, we showed that with just $250 per month, VectorChord achieved 131 QPS with 0.95 precision on 100 million vectors—demonstrating impressive cost-effective performance for large-scale vector search.

Building on that success, this post focuses on high performance by exploring how VectorChord can reach 10,000 QPS in PostgreSQL. We’ll walk you through how PostgreSQL’s reliable relational foundation integrates with advanced vector indexing to deliver fast, scalable search capabilities, and provide a production-ready setup along with a detailed architecture guide for managing large-scale vector computations even under heavy loads.

VectorChord-BM25: Revolutionize PostgreSQL Search with BM25 Ranking — 3x Faster Than ElasticSearch

Mon, 24 Feb 2025 00:00:00 +0000

We’re excited to share something special with you: VectorChord-BM25, a new extension designed to make PostgreSQL’s full-text search even better. Whether you’re building a small app or managing a large-scale system, this tool brings advanced BM25 scoring and ranking right into PostgreSQL, making your searches smarter and faster.

What’s New?

BM25 Scoring & Ranking: Get more precise and relevant search results with BM25, helping you find what matters most.
Optimized Indexing: Thanks to the Block WeakAnd algorithm, searches are quicker and more efficient, even with large datasets.
Enhanced Tokenization: Improved stemming and stop word handling mean better accuracy and smoother performance.

VectorChord 0.2: 60K-Dimensional Vectors, 50% Faster Indexing with ARM

Mon, 17 Feb 2025 00:00:00 +0000

Today, we’re thrilled to share VectorChord 0.2—a release shaped by community feedback and designed to tackle the evolving challenges of vector search in PostgreSQL.

%[https://github.com/tensorchord/VectorChord/]

Optimized Storage Layout: Supporting Up to 60,000 Dimensions

In PostgreSQL, the foundational storage unit is an 8KB page. While this design is robust for many workloads, it introduces constraints for modern use cases like high-dimensional vector search. For instance, pgvector faces a hard limit of 2000 dimensions per vector due to this fixed page size, as larger vectors cannot be indexed within a single page.

ARM + VectorChord: Affordable, Fast Vector Search

Tue, 21 Jan 2025 00:00:00 +0000

ARM64 is quietly becoming a go-to for cost-effective cloud servers, especially on AWS. With ARM-based processors like the Graviton series (Graviton3 and Graviton4), you can save a good chunk of money without sacrificing performance. These ARM64 instances are way more affordable than traditional x86 ones, making them a solid choice for balancing cost and performance in the cloud.

That said, ARM’s architecture differs from x86, so software that isn’t optimized for it might run slower due to emulation. This is where VectorChord steps in—a PostgreSQL extension designed for scalable, high-performance, and disk-efficient vector similarity search. As the successor to pgvecto.rs, VectorChord lets you store a whopping 400,000 vectors for just $1, delivering massive savings: 6x more vectors than Pinecone’s optimized storage and 26x more than pgvector / pgvecto.rs for the same price.

Benefits and Steps of External Centroids Building in VectorChord

Tue, 10 Dec 2024 00:00:00 +0000

Clustering is an important component in vector search, and the k-means algorithm remains one of the most widely used techniques. However, its simplicity comes with a significant drawback: resource-intensive computation can render it impractical for large datasets. This blog explores why this challenge arises and how leveraging external builds to overcome it. We also share insights into our approach to implementing this solution.

Why we need it

VectorChord uses IVF + RaBitQ to perform vector search. The quality of the IVF cluster can heavily affect search precision and speed. K-means usually takes dozens of rounds before convergence. For each round, all the sampled vectors need to be assigned to the nearest cluster. This is the most computationally intensive part. The good news is that this process can be easily parallelized.

VectorChord: Store 400k Vectors for $1 in PostgreSQL

Thu, 05 Dec 2024 00:00:00 +0000

We’re pleased to announce our new vector search extension for PostgreSQL, providing a highly cost-effective way to manage large vectors. Using VectorChord, you can achieve a QPS of 131 with 0.95 precision on 100 million 768-dimensional vectors for the top 10 queries. This setup costs only $250 monthly and can be hosted on a single machine.

This means you can store 400k vectors for only $1, allowing you to save significantly: 6x more vectors compared to Pinecone (storage optimized instance) and 26x more than pgvector/pgvecto.rs for the same price.