Vchord: Scalable Vector Search for PostgreSQL on Vchord

Cloud Limits

Mon, 01 Jan 0001 00:00:00 +0000

Learn about the limits and restrictions you should know about your operations on VectorChord Cloud:

Free Tier: One account can create only one free tier cluster.
Project: One account can belong to maximum five projects.
Does not support HA (High Availability) mode yet.

Cloud Pricing

Mon, 01 Jan 0001 00:00:00 +0000

Free Tier

In VectorChord Cloud, we provide a free tier that allows you learn and explore fully-managed VectorChord services in a cloud environment. Every user can use the free tier to create only one cluster and store vector data in it. There are some limitations in the free tier:

Shared resources
Limited storage for WAL(Write-Ahead Log) and PGData (5Gi)
Only support AWS T3 XLarge instance type
Capacity of 100k vectors with 1024 dimensions, this is an estimate, and you can also insert 25k vectors with 4096 dimensions.

Configuration

Mon, 01 Jan 0001 00:00:00 +0000

Logging

By default, you cannot capture all pgvecto.rs logs. pgvecto.rs starts a background worker process for indexing, and it prints logs to standard error. To capture them, you need to set logging_collector to on. You can get more information from PostgreSQL document about logging collector.

You can set logging_collector to on with the following command:

psql -U postgres -c 'ALTER SYSTEM SET logging_collector = on;'
# You need restart the PostgreSQL cluster to take effects.
sudo systemctl restart postgresql.service   # for pgvecto.rs running with systemd
docker restart pgvecto-rs-demo  # for pgvecto.rs running in docker

Index configuration

since v0.3.0

For each index, there are a number of configuration items that are variable. Unlike options, they support real-time modification after the index has been created. These items can be configured by function alter_vector_index.

Connecting with psql

Mon, 01 Jan 0001 00:00:00 +0000

The following instructions require a working installation of psql. The psql client is the native command-line client for Postgres. It provides an interactive session for sending commands to Postgres and running ad-hoc queries. For more information about psql, refer to the psql reference, in the PostgreSQL Documentation.

Warning

Cluster instance runs Postgres, which means that any Postgres application or standard utility such as psql is compatible with VectorChord Cloud. You can also use Postgres client libraries and drivers to connect. However, please be aware that some older client libraries and drivers, including older psql executables, are built without Server Name Indication (SNI) support and require a workaround.

Contributing to `pgvecto.rs`

Mon, 01 Jan 0001 00:00:00 +0000

We welcome all kinds of contributions from the open-source community, individuals, and partners. If you’re interested in contributing, hopefully, this document makes the process for contributing clear.

Contributors and people new to open source alike will find the following guides especially useful:

👀 How to Contribute to Open Source | Open Source Guides

Code of conduct

A code of conduct is a document that establishes expectations for behavior for the project’s participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for the community.

Subscribe by Adding Credit Card

Mon, 01 Jan 0001 00:00:00 +0000

Tip

Billing is for the project, not the user. There are separate invoices for each project, and you must add the payment method separately.

VectorChord Cloud supports credit card payments. You can add multiple credit cards or remove some of them by clicking Delete. Already added credit cards will be displayed on the billing page.

The Add Payment Method button will take you to Stripe’s Add Credit Card page where we will initiate a credit card pre-authorization request. There is no charge for this request. Once the add request is complete, the new credit card will be available and displayed on the Billing page.

Development

Mon, 01 Jan 0001 00:00:00 +0000

Set up development environment

You can set up development environment simply using envd. It will create a docker container and install all the dependencies for you.

pip install envd
git clone https://github.com/tensorchord/pgvecto.rs.git
cd pgvecto.rs
envd up

Or you can setup development environment following these steps manually:

Install base dependency.

sudo apt install -y \
    bison \
    build-essential \
    ccache \
    flex \
    gcc \
    git \
    gnupg \
    libreadline-dev \
    libssl-dev \
    libxml2-dev \
    libxml2-utils \
    libxslt-dev \
    lsb-release \
    pkg-config \
    tzdata \
    xsltproc \
    zlib1g-dev

Install clang-16. Other versions of clang are not supported.

sudo sh -c 'echo "deb http://apt.llvm.org/$(lsb_release -cs)/ llvm-toolchain-$(lsb_release -cs)-16 main" >> /etc/apt/sources.list'
wget --quiet -O - https://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add -
sudo apt-get update
sudo apt-get install -y --no-install-recommends clang-16

Install Rust. Do not install rustc using a package manager.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Clone the Repository.

git clone https://github.com/tensorchord/pgvecto.rs.git
cd pgvecto.rs

Install cargo-pgrx.

cargo install cargo-pgrx --version $(grep -o 'pgrx = { version = "=[^"]*' Cargo.toml | cut -d = -f 4)
cargo pgrx init

cargo-pgrx is a helpful tool to develop a PostgreSQL extension. You can read the document in https://docs.rs/crate/cargo-pgrx/latest.

Leveraging 3 Billion PostgreSQL Vectors: Earth Genome's Earth Index & VectorChord for Planetary Protection

Mon, 01 Jan 0001 00:00:00 +0000

Monitoring the health of our planet is one of the most critical challenges of our time. Our planet faces immense environmental pressures, and understanding these changes requires sifting through an unimaginable amount of satellite data – petabytes of pixels captured constantly. From tracking deforestation in the Amazon to identifying illegal mining operations in remote regions or monitoring agricultural impacts on sensitive ecosystems, turning this data into actionable intelligence is paramount.

General FAQ

Mon, 01 Jan 0001 00:00:00 +0000

Warning

We strongly suggest you explore our new VectorChord implementation, offering enhanced stability and performance. Users are advised to transition to VectorChord. Refer to the migration guide for assistance.

The vector type or operator class is not found

In most cases, this is due to a missing schema search path or a lack of permissions.

Please go through this checklist:

Run \dx with psql or SELECT * FROM pg_extension; and check if the extension exists.

postgres=# \dx
                                                    List of installed extensions
  Name   |    Version    |   Schema   |                                         Description                                          
---------+---------------+------------+----------------------------------------------------------------------------------------------
 vectors | 0.3.0         | vectors    | vectors: Vector database plugin for Postgres, written in Rust, specifically designed for LLM

If not, install it with CREATE EXTENSION vectors;

Half-Precision Vector: `vecf16`

Mon, 01 Jan 0001 00:00:00 +0000

Stored as a half-precision number format, vecf16 takes advantage of the 16-bit float, which uses half the memory and bandwidth compared to vector.

Here’s an example of creating a table with a vecf16 column and inserting values:

CREATE TABLE items (
  id bigserial PRIMARY KEY,
  embedding vecf16(3) NOT NULL
);

INSERT INTO items (embedding) VALUES ('[0.1, 0.2, 0]'), ('[0, 0.1, 0.2]');

Index can be created on vecf16 type as well.

Hybrid search with Postgres Native BM25 and VectorChord

Mon, 01 Jan 0001 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.

Hybrid Search

Mon, 01 Jan 0001 00:00:00 +0000

We will show you how to use pgvecto.rs to implement hybrid search in this section.

Vector Search and Full Text Search

Postgres provides full text search, based on the match operator @@. It returns true if a tsvector (document) matches a tsquery (query). It doesn’t matter which data type is written first:

SELECT 'a fat cat sat on a mat and ate a fat rat'::tsvector @@ 'cat & rat'::tsquery;
 ?column?
----------
 t

SELECT 'cat & rat'::tsquery @@ 'a fat cat sat on a mat and ate a fat rat'::tsvector;
 ?column?
----------
 t

Tip

As the above example suggests, a tsquery is not just raw text, any more than a tsvector is. A tsquery contains search terms, which must be already-normalized lexemes, and may combine multiple terms using AND, OR, NOT, and FOLLOWED BY operators. In this example, the tsquery 'cat & rat' matches the tsvector 'a fat cat sat on a mat and ate a fat rat' because it contains both the terms 'cat' and 'rat'.

Indexing

Mon, 01 Jan 0001 00:00:00 +0000

VectorChord’s index type vchordrq divides vectors into lists and searches only a subset of lists closest to the query vector. It provides fast build time and low memory consumption, while delivering significantly better performance than both hnsw and ivfflat.

Let’s start by creating a table named items with an embedding column of type vector(n), and then populate it with sample data.

CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(3));
INSERT INTO items (embedding) SELECT ARRAY[random(), random(), random()]::real[] FROM generate_series(1, 1000);

To create a vchordrq index, you can use the following SQL.

Indexing

Mon, 01 Jan 0001 00:00:00 +0000

Indexing is the process of building a data structure that allows for efficient search. pgvecto.rs supports three indexing algorithms: brute force (flat), IVF, and HNSW. The default algorithm is HNSW.

To construct an index for vectors, first create a table named items with a column named embedding of type vector(n). Then, populate the table with generated data.

CREATE TABLE items (embedding vector(3));
INSERT INTO items (embedding) SELECT ARRAY[random(), random(), random()]::real[] FROM generate_series(1, 1000);

Tip

vector is the suitable data type for most situations. pgvecto.rs also supports other specific vector types, including:

Half-Precision Vector
8-Bit Integer Vector since v0.3.0
Sparse Vector since v0.3.0
Binary Vector since v0.3.0

Indexing & Maintenance

Mon, 01 Jan 0001 00:00:00 +0000

vchord_bm25 provides the bm25 index access method (CREATE ACCESS METHOD bm25 TYPE INDEX HANDLER _bm25_amhandler) and the bm25_ops operator class.

Creating a `bm25` Index

Stable Releases (`v0.1` – `v0.3`, `bm25vector`)

CREATE INDEX documents_embedding_bm25
ON documents
USING bm25 (embedding bm25_ops);

Next-Gen `main` Branch (`tsvector`)

In the main branch, bm25_ops operates on tsvector and supports index-level storage parameters (options, limit, and prefilter):

LangChain

Mon, 01 Jan 0001 00:00:00 +0000

This document describes the LangChain integration.

LangChain is a framework for developing applications powered by language models. It is a set of tools that allows you to fine-tune, deploy, and use language models in production.

pgvecto.rs provides a LangChain integration that allows you to retrieve the most similar vectors in LangChain.

Install dependencies

Some dependencies are required to use the LangChain integration:

pip install langchain langchain-openai pgvecto-rs

You could start the postgres instance with pgvecto.rs extension in a docker container:

License

Mon, 01 Jan 0001 00:00:00 +0000

Software License (`pgsty/vchord` & `pgsty/vchord_bm25`)

pgsty/vchord and pgsty/vchord_bm25 are licensed under the GNU Affero General Public License v3.0 (AGPL-3.0-only):

pgsty/vchord LICENSE
pgsty/vchord_bm25 LICENSE

Software License (`pgsty/pg_tokenizer`)

pgsty/pg_tokenizer is licensed under the Apache License 2.0 (Apache-2.0):

pgsty/pg_tokenizer LICENSE

Documentation License (`vchord.pgsty.com`)

The documentation and site adaptations in pgsty/vchord.pgsty.com are licensed under the Creative Commons Attribution 4.0 International License (CC-BY-4.0), with upstream materials adapted from tensorchord/pgvecto.rs-docs and blog.vectorchord.ai.

Migration

Mon, 01 Jan 0001 00:00:00 +0000

outline: [2,3]

VectorChord Migration Overview

From PGVecto.rs

Most of VectorChord’s vector types are supported by pgvector. Therefore, migrating from PGVecto.rs to VectorChord is a simple inversion of migrating from pgvector to PGVecto.rs.

Tip

We provide migration image modelzai/pgvectors-vchord for pgvecto.rs to VectorChord and vice versa.

Prerequisites

Let’s suppose that you have a table with vector data, and the extension PGVecto.rs installed. A simple example would be:

Monitoring

Mon, 01 Jan 0001 00:00:00 +0000

The VectorChord Cloud provides several graphs for monitoring system and database metrics. You can access the Metrics dashboard from the cluster details in the VectorChord Cloud Console. Observable metrics include:

Storage Usage

This graph shows the total and usage of the storage of Postgres instance.

RAM

This graph shows the average memory usage of the Postgres instance, the unit is in MB.

Overview

Mon, 01 Jan 0001 00:00:00 +0000

PostgreSQL includes built-in full-text search via tsvector, tsquery, ts_rank, and GIN indexes. While effective for boolean keyword matching (@@), PostgreSQL’s built-in ranking has two structural limitations for modern search and Retrieval-Augmented Generation (RAG) workloads:

Suboptimal Ranking Formula (ts_rank): PostgreSQL’s ts_rank and ts_rank_cd do not track corpus-wide Inverse Document Frequency (IDF) or Average Document Length ( $\text{avgdl}$ ) across the index. Common words are weighted the same as rare, high-signal terms, and term frequency is not properly saturated.
Exhaustive Index Scans on ORDER BY ... LIMIT K: A PostgreSQL GIN index only accelerates boolean matching (WHERE tsv @@ tsquery). To return the Top-10 highest-ranked documents, PostgreSQL must fetch every matching row from the heap, compute ts_rank for all of them, and sort the entire result set.

How VectorChord-BM25 Solves Both Problems

VectorChord-BM25 (vchord_bm25) introduces a dedicated PostgreSQL index access method (USING bm25) and sparse BM25 scoring operator (<&>) specifically engineered for Top-K lexical retrieval:

Overview of the cloud object hierarchy

Mon, 01 Jan 0001 00:00:00 +0000

Managing your VectorChord Cloud project requires an understanding of the object hierarchy. The following diagram shows how objects in cloud are related. See below for a description of each object.

VectorChord Cloud Account

This is the account you used to sign up with VectorChord Cloud. Now supports signing up with an GitHub account.

Projects

A project is the top-level object in the hierarchy. It is a container for all clusters in the project and billing information. For more information, see Projects.

Overview

Mon, 01 Jan 0001 00:00:00 +0000

vchord is a PostgreSQL extension designed for scalable, high-performance, and disk-efficient vector similarity search.

With vchord, you can store 400,000 vectors for just $1, enabling significant savings: 6x more vectors compared to Pinecone’s optimized storage and 26x more than pgvector/pgvecto.rs for the same price¹. For further insights, check out our launch blog post.

Features

vchord introduces remarkable enhancements over pgvecto.rs and pgvector:

⚡ Enhanced Performance: Delivering optimized operations with up to 5x faster queries, 16x higher insert throughput, and 16x quicker¹ index building compared to pgvector’s HNSW implementation.

Overview

Mon, 01 Jan 0001 00:00:00 +0000

Warning

An introduction to the pgvecto.rs.

What is `pgvecto.rs`

pgvecto.rs is a Postgres extension that provides vector similarity search functions. It is written in Rust and based on pgrx. It is currently in the beta status, we invite you to try it out in production and provide us with feedback. Read more at 📝our launch blog.

Price Benchmark

Mon, 01 Jan 0001 00:00:00 +0000

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. If you are interested in the details of our implementation, please refer to our blog VectorChord: Store 400k Vectors for $1 in PostgreSQL.

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.

Schema

Mon, 01 Jan 0001 00:00:00 +0000

Here is the schema provided by pgvecto.rs.

List of data types

Name	Description
vector	vector, scalar type of which is `binary32` defined in IEEE 754-2008
vecf16	vector, scalar type of which is `binary16` defined in IEEE 754-2008
veci8	vector, scalar type of which is `8-bit Integer`
svector	sparse vector, scalar type of which is `binary32` defined in IEEE 754-2008
bvector	binary vector, a fixed-length bit string
vector_index_stat	a composite type representing vector index statistics

List of operators

Name	Left arg type	Right arg type	Result type	Description
+	vector	vector	vector	element-wise arithmetic
+	vecf16	vecf16	vecf16	element-wise arithmetic
+	veci8	veci8	veci8	element-wise arithmetic
+	svector	svector	svector	element-wise arithmetic
-	vector	vector	vector	element-wise arithmetic
-	vecf16	vecf16	vecf16	element-wise arithmetic
-	veci8	veci8	veci8	element-wise arithmetic
-	svector	svector	svector	element-wise arithmetic
&	bvector	bvector	bvector	element-wise logical AND
\|	bvector	bvector	bvector	element-wise logical OR
^	bvector	bvector	bvector	element-wise logical XOR
=	vector	vector	boolean	dictionary order comparison
=	vecf16	vecf16	boolean	dictionary order comparison
=	veci8	veci8	boolean	dictionary order comparison
=	svector	svector	boolean	dictionary order comparison
=	bvector	bvector	boolean	dictionary order comparison
<>	vector	vector	boolean	dictionary order comparison
<>	vecf16	vecf16	boolean	dictionary order comparison
<>	veci8	veci8	boolean	dictionary order comparison
<>	svector	svector	boolean	dictionary order comparison
<>	bvector	bvector	boolean	dictionary order comparison
<	vector	vector	boolean	dictionary order comparison
<	vecf16	vecf16	boolean	dictionary order comparison
<	veci8	veci8	boolean	dictionary order comparison
<	svector	svector	boolean	dictionary order comparison
<	bvector	bvector	boolean	dictionary order comparison
>	vector	vector	boolean	dictionary order comparison
>	vecf16	vecf16	boolean	dictionary order comparison
>	veci8	veci8	boolean	dictionary order comparison
>	svector	svector	boolean	dictionary order comparison
>	bvector	bvector	boolean	dictionary order comparison
<=	vector	vector	boolean	dictionary order comparison
<=	vecf16	vecf16	boolean	dictionary order comparison
<=	veci8	veci8	boolean	dictionary order comparison
<=	svector	svector	boolean	dictionary order comparison
<=	bvector	bvector	boolean	dictionary order comparison
>=	vector	vector	boolean	dictionary order comparison
>=	vecf16	vecf16	boolean	dictionary order comparison
>=	veci8	veci8	boolean	dictionary order comparison
>=	svector	svector	boolean	dictionary order comparison
>=	bvector	bvector	boolean	dictionary order comparison
<->	vector	vector	real	squared Euclidean distance
<->	vecf16	vecf16	real	squared Euclidean distance
<->	veci8	veci8	real	squared Euclidean distance
<->	svector	svector	real	squared Euclidean distance
<->	bvector	bvector	real	squared Euclidean distance
<#>	vector	vector	real	negative dot product
<#>	vecf16	vecf16	real	negative dot product
<#>	veci8	veci8	real	negative dot product
<#>	svector	svector	real	negative dot product
<#>	bvector	bvector	real	negative dot product
<=>	vector	vector	real	cosine distance
<=>	vecf16	vecf16	real	cosine distance
<=>	veci8	veci8	real	cosine distance
<=>	svector	svector	real	cosine distance
<=>	bvector	bvector	real	cosine distance
<~>	bvector	bvector	real	jaccard distance

List of functions

Name	Argument type	Result type	Description
pgvectors_upgrade		void	Administration function for upgrading `pgvecto.rs`.
to_svector	dims integer, index integer[], value real[]	svector	Construct a sparse vector from two arrays of indexes and values
binarize	vector vector	bvector	Binarize a vector. All positive elements are set to 1, otherwise 0.
text2vec_openai	input text, model text	vector	Embedding function for OpenAI embeddings API.
text2vec_openai_v3	input text	vector	Embedding function for OpenAI embeddings API. The model is set to `text-embedding-3-small`.

List of casts

Source type	Target type	Implicit?
real[]	vector	yes
vector	real[]	yes
vector	vecf16	no
vecf16	vector	no
vector	veci8	no
veci8	vector	no
vector	svector	no
svector	vector	no
vector	bvector	no
bvector	vector	no

List of access methods

Name	Type	Description
vectors	Index	pgvecto.rs vector index

List of operator families

AM	Operator family	Applicable types
vectors	vector_cos_ops	vector
vectors	vector_dot_ops	vector
vectors	vector_l2_ops	vector
vectors	vecf16_cos_ops	vecf16
vectors	vecf16_dot_ops	vecf16
vectors	vecf16_l2_ops	vecf16
vectors	veci8_cos_ops	veci8
vectors	veci8_dot_ops	veci8
vectors	veci8_l2_ops	veci8
vectors	svector_cos_ops	svector
vectors	svector_dot_ops	svector
vectors	svector_l2_ops	svector
vectors	bvector_cos_ops	bvector
vectors	bvector_dot_ops	bvector
vectors	bvector_l2_ops	bvector
vectors	bvector_jaccard_ops	bvector

List of operator classes

AM	Input type	Operator class	Default?	Description
vectors	vector	vector_l2_ops	no	squared Euclidean distance
vectors	vector	vector_dot_ops	no	negative dot product
vectors	vector	vector_cos_ops	no	cosine distance
vectors	vecf16	vecf16_l2_ops	no	squared Euclidean distance
vectors	vecf16	vecf16_dot_ops	no	negative dot product
vectors	vecf16	vecf16_cos_ops	no	cosine distance
vectors	veci8	veci8_l2_ops	no	squared Euclidean distance
vectors	veci8	veci8_dot_ops	no	negative dot product
vectors	veci8	veci8_cos_ops	no	cosine distance
vectors	svector	svector_l2_ops	no	squared Euclidean distance
vectors	svector	svector_dot_ops	no	negative dot product
vectors	svector	svector_cos_ops	no	cosine distance
vectors	bvector	bvector_l2_ops	no	squared Euclidean distance
vectors	bvector	bvector_dot_ops	no	negative dot product
vectors	bvector	bvector_cos_ops	no	cosine distance
vectors	bvector	bvector_jaccard_ops	no	jaccard distance

List of views

Name	Description
pg_vector_index_stat	A view provided for vector index statistics

Sign up for a cloud account

Mon, 01 Jan 0001 00:00:00 +0000

For information about what’s included with the Cloud Free Tier, see Cloud Free Tier. For information about Cloud’s paid plan options, see Cloud plans.

Signing up for VectorChord Cloud is easy. Simply navigate to https://cloud.vectorchord.ai and sign up with your Github account.

After signing up, you are directed to the VectorChord Cloud Console. We will create a default project.

SQL Reference

Mon, 01 Jan 0001 00:00:00 +0000

`vchord_bm25` Data Types

Data Type	Schema	Versions	Text Representation / Structure	Description
`bm25vector`	`bm25_catalog`	`v0.1.0` – `v0.3.0`	`{token_id:freq, ...}` (e.g., `{1:1, 2:2, 15:1}`)	Sparse vector mapping 32-bit unsigned token IDs to 32-bit term frequencies. Stored with `STORAGE = EXTERNAL`.
`bm25query`	`bm25_catalog`	`v0.1.0` – `v0.3.0`	`(index_oid regclass, query_vector bm25vector)`	Composite type pairing a target `bm25` index OID with a query `bm25vector`.
`bm25query`	`public` / ext schema	`main`	`(vector tsvector, index regclass)`	Composite type pairing a query `tsvector` with a target `bm25` index OID.

`bm25vector` Literal Syntax (`v0.1` – `v0.3`)

-- Empty bm25vector
SELECT '{}'::bm25vector;

-- Explicit token_id:frequency pairs
SELECT '{1:1, 2:3, 10:2}'::bm25vector;

-- Implicit cast from int[] (automatically aggregates duplicate token IDs into counts)
SELECT ARRAY[1, 2, 2, 2, 10, 10]::bm25vector;
-- Output: {1:1, 2:3, 10:2}

`vchord_bm25` Operators

Operator	Left Arg	Right Arg	Return Type	Versions	Description
`<&>`	`bm25vector`	`bm25query`	`real` (`f32`)	`v0.1.0` – `v0.3.0`	Computes the negative BM25 relevance score ($-\text{BM25}(D, Q)$). Supports index-accelerated `ORDER BY ... ASC` scans using `bm25_ops`.
`<&>`	`tsvector`	`bm25query`	`float8` (`f64`)	`main`	Computes the negative BM25 relevance score on native `tsvector`. Supports index-accelerated `ORDER BY ... ASC` scans using `bm25_ops`.
`=`	`bm25vector`	`bm25vector`	`bool`	`v0.2.0` – `v0.3.0`	Exact equality comparison between two `bm25vector` values.
`<>`	`bm25vector`	`bm25vector`	`bool`	`v0.2.0` – `v0.3.0`	Inequality comparison between two `bm25vector` values.

`vchord_bm25` Functions

Function Signature	Return Type	Versions	Description
`to_bm25query(index_oid regclass, query_vector bm25vector)`	`bm25query`	`v0.1.1` – `v0.3.0`	Constructs a `bm25query` from a `bm25` index name/OID and a query `bm25vector` (or `INT[]` via implicit cast).
`to_bm25query(index_oid regclass, query_vector int[])`	`bm25query`	`v0.3.0+`	Explicit overload accepting an `INT[]` token ID array directly.
`to_bm25query(vector tsvector, index regclass)`	`bm25query`	`main`	Constructs a `bm25query` from a native `tsvector` and target `bm25` index name/OID.
`search_bm25query(target_vector bm25vector, query bm25query)`	`real`	`v0.1.0` – `v0.3.0`	Underlying implementation function for `bm25vector <&> bm25query`.
`_bm25_evaluate(left tsvector, right bm25query)`	`float8`	`main`	Underlying implementation function for `tsvector <&> bm25query`.
`bm25_page_inspect(index regclass, blkno int)`	`text`	`v0.3.0`	Returns human-readable diagnostic metadata for block `blkno` of a `bm25` index.

`vchord_bm25` Access Method & Operator Class

Object	Name	Target Type	Ordering Operator
Access Method	`bm25`	Index	Handler `_bm25_amhandler`
Operator Family	`bm25_ops`	`USING bm25`	`OPERATOR 1 pg_catalog.<&> FOR ORDER BY float_ops`
Operator Class	`bm25_ops`	`bm25vector` (`v0.1`–`v0.3`) / `tsvector` (`main`)	Default operator class for `USING bm25`

`pg_tokenizer` Functions (`tokenizer_catalog`)

All pg_tokenizer functions reside in the tokenizer_catalog schema:

Tokenizer Architecture & Usage

Mon, 01 Jan 0001 00:00:00 +0000

Two-Stage Tokenization Pipeline

A tokenizer in pg_tokenizer consists of up to two stages that transform a raw TEXT string into an INT[] array of integer token IDs:

flowchart LR
    A["Raw Text\\n(TEXT)"] --> B["Stage 1: Text Analyzer\\n1. character_filters\\n2. pre_tokenizer\\n3. token_filters"]
    B --> C["Normalized Tokens\\n(TEXT[])"]
    C --> D["Stage 2: Model\\nVocabulary Mapping / Subword BPE"]
    D --> E["Token ID Array\\n(INT[] → bm25vector)"]

Text Analyzer (text_analyzer): Splits raw text into a TEXT[] array of normalized string tokens by applying a sequential pipeline of:
- Character Filters (character_filters): Transform the raw string before splitting (e.g., to_lowercase, unicode_normalization).
- Pre-tokenizer (pre_tokenizer): Splits the string into initial substrings (unicode_segmentation, regex, or Chinese jieba).
- Token Filters (token_filters): Filter or transform individual tokens (skip_non_alphanumeric, stemmer, stopwords, synonym, pg_dict, ngram).
Model (model): Maps the string tokens (or raw text, for standalone subword models like llmlingua2, bert_base_uncased, gemma2b, HuggingFace, or lindera) into integer token IDs (INT[]).

Note

Pretrained subword models (llmlingua2, bert_base_uncased, gemma2b), HuggingFace models, and Lindera models include their own built-in tokenization rules and do not require a separate text_analyzer stage.
Dictionary/corpus models (wiki_tocken and custom models created via create_custom_model) require a text_analyzer stage to split and normalize text before looking up token IDs in the model’s vocabulary table.

Creating and Using a Tokenizer

All configuration in pg_tokenizer uses TOML format passed as a dollar-quoted string ($$ ... $$).

Troubleshooting

Mon, 01 Jan 0001 00:00:00 +0000

Connectivity

1. Cluster is not reachable, you can check the following:

If the status of the cluster, if it is NotReady, you can check the metrics of the cluster to see if there are free space for PGData.

Warning

Do not delete your cluster, it will cause data loss.

Solution:

You can upgrade your cluster to a larger size to solve the problem, you can refer to the upgrade cluster storage for more information. After the upgrade is completed, the cluster will be in the Ready status, and the cluster will be reachable.

If above solution does not work, you can contact us at Discord, we are happy to help.

8-Bit Integer Vector: `veci8`

Mon, 01 Jan 0001 00:00:00 +0000

since v0.3.0

Int8 is a data type used to represent signed integers. It stands for “integer 8-bit” and typically uses 8 bits of memory to store a value. This allows it to represent integer values ranging from -128 to 127.

Since each element in the vector only requires 8 bits (1 byte) of memory, veci8 can help reduce the overall memory footprint of your program.

Here’s an example of creating a table with a veci8 column and inserting values:

Adaptive retrieval and shortening embeddings

Mon, 01 Jan 0001 00:00:00 +0000

OpenAI latest embedding models support shortening embeddings, where developers could simply “remove some numbers from the end of a sequence” and still maintain a valid representation for text.

This enables very flexible usage. For example, when using a vector data store that only supports embeddings up to 1024 dimensions long, developers can now still use our best embedding model text-embedding-3-large and specify a value of 1024 for the dimensions API parameter, which will shorten the embedding down from 3072 dimensions, trading off some accuracy in exchange for the smaller vector size.

Attribution & Provenance

Mon, 01 Jan 0001 00:00:00 +0000

vchord.pgsty.com is maintained by PGSTY to provide a comprehensive, searchable documentation and engineering reference for the Vchord extension suite (vchord, vchord_bm25, and pg_tokenizer).

Upstream Sources

Documentation (content/docs/, content/cloud/, content/pgvecto-rs/)
- Source Repository: https://github.com/tensorchord/pgvecto.rs-docs
- Original Site: https://docs.vectorchord.ai/
- Copyright: © 2023–Present TensorChord Inc. and Contributors.
- Adaptations: Converted from VitePress to Hugo + OINK v1.4.0, including GitHub-style callout normalization, KaTeX math delimiter standardization, internal link resolution, and structural navigation metadata.
Engineering Blog & Release Notes (content/blog/)
- Original Publication: https://blog.vectorchord.ai/
- Copyright: © 2023–Present TensorChord Inc. and respective article authors (Keming, Haze, VoVAllen, Yifanwang, Kolkri, Gin, Scase).
- Adaptations: Archived into content/blog/post/ and content/blog/release/ with original publication dates, author metadata, and direct upstream_link provenance pointers.
Vchord Extension Suite (vchord, vchord_bm25, and pg_tokenizer)
- vchord (pgsty/vchord) Forked From: https://github.com/supervc-stack/VectorChord (formerly tensorchord/VectorChord)
- vchord_bm25 (pgsty/vchord_bm25) Forked From: https://github.com/supervc-stack/VectorChord-bm25 (formerly tensorchord/VectorChord-bm25)
- pg_tokenizer (pgsty/pg_tokenizer) Forked From: https://github.com/supervc-stack/pg_tokenizer.rs (formerly tensorchord/pg_tokenizer.rs)
- Predecessor Project: https://github.com/tensorchord/pgvecto.rs

Supercharge vector search with ColBERT rerank in PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

Traditional vector search methods typically employ sentence embeddings to locate similar content. However, generating sentence embeddings through pooling token embeddings can potentially sacrifice fine-grained details present at the token level. ColBERT overcomes this by representing text as token-level multi-vectors rather than a single, aggregated vector. This approach, leveraging contextual late interaction at the token level, allows ColBERT to retain more nuanced information and improve search accuracy compared to methods relying solely on sentence embeddings.

Collect Metrics

Mon, 01 Jan 0001 00:00:00 +0000

VectorChord Cloud shows some database metrics on cloud.vectorchord.ai. If you want to collect metrics from your database into your self-hosted metrics system, you can follow this guide. Metrics detail can be found in the Appendix section.

Where to find your metrics

You can find your metrics on your database’s domain name with the metrics endpoint. You must provide a VectorChord Cloud API Key in order to access these metrics. You can generate a API Key from the API Keys section.

GUC & Index Parameters

Mon, 01 Jan 0001 00:00:00 +0000

Stable Releases (`v0.1.0` – `v0.3.0`): `bm25_catalog.*` GUCs

In versions v0.1.0 through v0.3.0, all session GUC parameters use the bm25_catalog. prefix and can be changed per session or transaction by any user (GucContext::Userset):

Parameter Name	Type	Default	Valid Range	Description
`bm25_catalog.bm25_limit`	`integer`	`100`	`-1` .. `65535`	Maximum number of top-scoring documents to return from a `bm25` index scan. Set to `-1` to disable Block-WeakAnd pruning and perform an exhaustive brute-force scan; set to `0` to return no rows. Must be $\ge$ your SQL `LIMIT`.
`bm25_catalog.enable_index`	`boolean`	`true`	`true` / `false`	Enables or disables the `bm25` index scan in the PostgreSQL query planner. Set to `false` to force a sequential scan with exact `search_bm25query` evaluation.
`bm25_catalog.enable_prefilter`	`boolean`	`true`	`true` / `false`	Introduced in `v0.2.2`. When `true`, filters out documents that do not satisfy the query/visibility check before inserting them into the Block-WeakAnd Top-K heap.
`bm25_catalog.segment_growing_max_page_size`	`integer`	`4096`	`1` .. `1000000`	Maximum size (in 8 KB pages, default `4096` = 32 MB) of the append-only growing segment before it is sealed into a compressed, delta-bitpacked read-only segment.

Examples (`v0.1` – `v0.3`)

-- Increase Top-K window for deep pagination (e.g., LIMIT 500)
SET bm25_catalog.bm25_limit = 500;

-- Force brute-force scan over all index postings
SET bm25_catalog.bm25_limit = -1;

-- Enable prefiltering for queries with selective WHERE clauses
SET bm25_catalog.enable_prefilter = true;

-- Disable index scan to benchmark sequential scan baseline
SET bm25_catalog.enable_index = false;

Next-Gen `main` Branch: `bm25.*` GUCs & Index Reloptions

In the main branch rewrite, session GUCs use the bm25. prefix and work together with per-index storage parameters (WITH (...)):

Indexing Options

Mon, 01 Jan 0001 00:00:00 +0000

We utilize TOML syntax to express the index’s configuration. Here’s what each key in the configuration signifies:

Key	Type	Description
segment	table	Options for segments.
optimizing	table	Options for background optimizing.
indexing	table	The algorithm to be used for indexing.

Options for table `segment`

Key	Type	Range	Default	Description
max_growing_segment_size	integer	`[1, 4_000_000_000]`	`20_000`	Maximum size of unindexed vectors.
max_sealed_segment_size	integer	`[1, 4_000_000_000]`	`1_000_000`	Maximum size of vectors for indexing.

Options for table `optimizing`

Key	Type	Range	Default	Description
optimizing_threads	integer	`[1, 65535]`	sqrt of the number of cores	Maximum threads for indexing.
sealing_secs	integer	`[1, 60]`	`60`	See below.
sealing_size	integer	`[1, 4_000_000_000]`	`1`	See below.

If a write segment larger than sealing_size do not accept new data for sealing_secs seconds, the write segment will be turned to a sealed segment.

Installation

Mon, 01 Jan 0001 00:00:00 +0000

vchord_bm25 supports PostgreSQL 14, 15, 16, 17, and 18 on Linux (x86_64 and aarch64) and macOS.

Method 1: Pigsty / Native OS Packages (Recommended)

Pigsty provides pre-built native RPM and DEB packages for vchord, vchord_bm25, and pg_tokenizer across EL 8/9/10, Debian 12/13, and Ubuntu 22.04/24.04 for PostgreSQL 14–18.

# Install via Pigsty CLI (automatically resolves PG version and OS distro)
pig ext install vchord_bm25
pig ext install pg_tokenizer

Or install directly via apt / dnf once the Pigsty repository is configured:

Installation

Mon, 01 Jan 0001 00:00:00 +0000

VectorChord is tested on the following operating system:

Ubuntu (x86_64, aarch64)
MacOS (x86_64, aarch64)
Windows (x86_64)
Alpine Linux (x86_64, aarch64) ¹
Debian (powerpc64le, s390x, riscv64) ²

Please report a bug if you encounter issues on any of the above operating systems, or submit a feature request for additional platform support.

Docker

VectorChord Image

The easiest way to try VectorChord is to run it from a ready-to use Docker image.

Installation

Mon, 01 Jan 0001 00:00:00 +0000

Warning

We strongly encourage you to explore our new VectorChord implementation, which offers improved stability and performance. Users are encouraged to migrate to VectorChord. See the migration guide for assistance.

There are four ways to install pgvecto.rs.

Docker

The easiest way to try pgvecto.rs is to run it from a ready-to use Docker image.

docker run \
  --name pgvecto-rs-demo \
  -e POSTGRES_PASSWORD=mysecretpassword \
  -p 5432:5432 \
  -d tensorchord/pgvecto-rs:pg16-v0.2.0

Then you can connect to the database using the psql command line tool. The default username is postgres, and the default password is mysecretpassword.

View Invoice

Mon, 01 Jan 0001 00:00:00 +0000

Currently, the VectorChord Cloud has Orb as its billing provider. From the Billing page, you can click View invoices in Orb to go to the Orb Customer Portal. On this external page you can do the following:

Review your compute resource and storage usage
Review your invoices, both paid, issued, and draft
Pay invoices that have been unsuccessfully charged

Review the amount of usage

On the Overview page of the Customer Portal, the Current Billing Period section allows you to check your recent usage:

LlamaIndex

Mon, 01 Jan 0001 00:00:00 +0000

LlamaIndex is a simple, flexible data framework for connecting custom data sources to large language models (LLMs).

pgvecto.rs provides a LlamaIndex integration that allows you to retrieve the most similar vectors.

Install dependencies

Some dependencies are required to use the LlamaIndex integration:

pip install llama-index "pgvecto_rs[sdk]"

You could start the postgres instance with pgvecto.rs extension in a docker container:

docker run \
  --name pgvecto-rs-demo \
  -e POSTGRES_PASSWORD=mysecretpassword \
  -p 5432:5432 \
  -d tensorchord/pgvecto-rs:pg16-v0.2.0

Then you can connect to the database using the psql command line tool. The default username is postgres, and the default password is mysecretpassword.

Multi-Vector Retrieval

Mon, 01 Jan 0001 00:00:00 +0000

since v0.3.0

Multi-Vector Retrieval is an advanced technique used in Retrieval-Augmented Generation (RAG) systems to enhance document retrieval by leveraging multiple vectors per document.

Unlike Single-Vector Retrieval, Multi-Vector Retrieval using the MaxSim operator enables capturing fine-grained semantic relationships.

Refer to our blog for more details on building an end-to-end Multi-Vector Retrieval application.

How to start

Late interaction models embed documents and queries as vector arrays separately and compute similarity through an operator called MaxSim. The definition of the MaxSim operator is $\sum_i \max_j q_i \cdot d_j$ , meaning that for each vector in the query vector array, the closest vector in the document vector array is found, their dot product is calculated, and the results are summed.

Performance Benchmarking

Mon, 01 Jan 0001 00:00:00 +0000

Here we present a comprehensive benchmark comparing our implementation of VectorChord with other vector databases, focusing on QPS and scalability. If you are interested in the details of our implementation, please refer to our blog VectorChord: Store 400k Vectors for $1 in PostgreSQL.

QPS

LAION 5M

In LAION 5M dataset, VectorChord achieved more than 3x QPS at 0.95 recall compared to different vector databases, including MyScale, pgvector, pinecone, weaviate, qdrant and zilliz(milvus).

Comparison with pgvector

Mon, 01 Jan 0001 00:00:00 +0000

Original post: pgvector vs. pgvecto.rs in 2024: A Comprehensive Comparison for Vector Search in PostgreSQL

TL; DR: Please navigate directly to the final section that contains a table showcasing the main distinctions.

Search

Search is essential for a database. It plays a pivotal role in facilitating efficient data retrieval, enabling users to quickly find and access the information they need. We will demonstrate their performance and highlight the various features pgvecto.rs and pgvector offer.

Projects

Mon, 01 Jan 0001 00:00:00 +0000

With VectorChord Cloud, everything starts with the project. It is the top-level object in the hierarchy. A project can hold as many Postgres clusters as needed. The maximum number of projects you can create and join is 5.

Learn more about projects and how to manage them in these sections:

Project Setting

In project setting, you can view and edit the project information. You can switch to another project by clicking the project name in the bottom left corner of the page. The default project is the first project we created for you when you signed up. In below diagram, you can change the name, invite members to the project, and leave the project.

Querying & Scoring

Mon, 01 Jan 0001 00:00:00 +0000

Basic Top-K Query Syntax

To run an index-accelerated Top-K BM25 search, use the <&> operator in the ORDER BY clause together with to_bm25query:

-- v0.1 – v0.3 (bm25vector + pg_tokenizer)
SELECT
    id,
    passage,
    embedding <&> to_bm25query('documents_embedding_bm25', tokenize('PostgreSQL vector search', 'my_tokenizer')) AS raw_score,
    -(embedding <&> to_bm25query('documents_embedding_bm25', tokenize('PostgreSQL vector search', 'my_tokenizer'))) AS bm25_score
FROM documents
ORDER BY raw_score ASC
LIMIT 10;

-- main branch (native tsvector)
SELECT
    id,
    passage,
    -(vector <&> to_bm25query(to_tsvector('english', 'PostgreSQL vector search'), 'documents_bm25_idx')) AS bm25_score
FROM documents
ORDER BY vector <&> to_bm25query(to_tsvector('english', 'PostgreSQL vector search'), 'documents_bm25_idx') ASC
LIMIT 10;

Why `to_bm25query` Requires the Index Name

Unlike vector distance operators (where the distance between two vectors depends only on the two vectors themselves), the BM25 score of a document depends on corpus-wide statistics stored inside the BM25 index:

Quick Start

Mon, 01 Jan 0001 00:00:00 +0000

This guide will help you get started with VectorChord Cloud. First, you need to sign up for a VectorChord Cloud account. If you haven’t done so already, you can sign up for a free account here.

Create a cluster

Tip

You can only create Enterprise plan after you bind a credit card.

To create a new cluster, navigate to the VectorChord Cloud Console and click on the “Create Cluster” button.

Roadmap

Mon, 01 Jan 0001 00:00:00 +0000

Warning

Midterm Plan

Sparse Vector Support

Sparse vectors have shown excellent performance in tasks such as RAG and text retrieval, and can improve the results of dense vectors. Therefore, we plan to support sparse vector indexing.

Scalability

Mon, 01 Jan 0001 00:00:00 +0000

Background

High queries per second (QPS) vector search is essential for real-time applications such as recommendation engines, image recognition, and natural language processing. These applications demand rapid, efficient searches to deliver immediate results, which is critical for maintaining user engagement and operational effectiveness. By leveraging PostgreSQL for vector search, you not only benefit from its mature, robust relational capabilities and advanced indexing but also avoid the overhead of managing a separate, specialized vector database. This unified approach simplifies integration and reduces system complexity while still meeting the performance needs of modern applications.

Search

Mon, 01 Jan 0001 00:00:00 +0000

Get the nearest 5 neighbors to a vector

SET vectors.hnsw_ef_search = 64;
SELECT * FROM items ORDER BY embedding <-> '[3,2,1]' LIMIT 5;

Operators

These operators are used for distance metrics:

Name	Description
<->	squared Euclidean distance
<#>	negative dot product
<=>	cosine distance

For their definitions, see overview.

Filter

For a given category, get the nearest 10 neighbors to a vector

Text Analyzers & Filters

Mon, 01 Jan 0001 00:00:00 +0000

A Text Analyzer processes raw text through three sequential stages:

Character Filters (character_filters) — Zero or more character-level transformations on the full text string.
Pre-tokenizer (pre_tokenizer) — Exactly one splitter that breaks the string into initial tokens.
Token Filters (token_filters) — Zero or more token-level transformations, expansions, or filters.

SELECT create_text_analyzer('analyzer1', $$
character_filters = [
    "to_lowercase",
    { unicode_normalization = "nfkd" },
]
pre_tokenizer = "unicode_segmentation"
token_filters = [
    "skip_non_alphanumeric",
    { stopwords = "nltk_english" },
    { stemmer = "english_porter2" },
]
$$);

Tip

You can test any text analyzer directly using SELECT apply_text_analyzer('Sample text here', 'analyzer1'); to inspect the resulting TEXT[] array before wiring it to a model.

Upgrading

Mon, 01 Jan 0001 00:00:00 +0000

General Steps

If you update the extension to a new version, let’s say it’s a.b.c. This command helps you to update the schema of extension:

ALTER EXTENSION vectors UPDATE;
-- or
ALTER EXTENSION vectors UPDATE TO 'a.b.c';

If you’re upgrading from 0.1.x, please read Upgrading from 0.1.x.

If you’re upgrading to 0.4.0, please read Upgrading to 0.4.0.

Execute the following SQL. It helps you do some maintenance work.

Adopters

Mon, 01 Jan 0001 00:00:00 +0000

immich is a self-hosted photo and video backup solution directly from your mobile phone. it is using pgvecto.rs to search.
postgresql_embedded is a set of utilities for installing, running and managing PostgreSQL and extensions in Rust with support for installing pgvecto.rs.

Add your app here

If you are using pgvecto.rs in your app, please edit this page. We are glad to get your feedback and help you to improve your experience with pgvecto.rs.

Benchmarks

Mon, 01 Jan 0001 00:00:00 +0000

Throughput Benchmark (QPS vs. Elasticsearch, Lucene, ParadeDB, PG GIN)

VectorChord-BM25’s Block-WeakAnd implementation with 128-document delta-bitpacked blocks and 1-byte fieldnorm quantization delivers up to 3x higher QPS than Tantivy-based PostgreSQL extensions (ParadeDB / pg_search) and an order of magnitude higher QPS than native PostgreSQL GIN indexes on Top-10 ranked queries:

Why `vchord_bm25` Achieves High QPS

Zero Cross-Engine Serialization: Unlike foreign-data-wrapper or external Tantivy/Lucene bridges, vchord_bm25 stores its segments directly inside PostgreSQL buffer pages (PostgresRelation), avoiding tuple marshaling overhead.
Aggressive Block-Max Pruning: On multi-term queries, Block-WeakAnd skips over 80%–95% of 128-document posting blocks without decompressing them once the Top-10 threshold stabilizes.
256-Entry Precomputed BM25 Lookup Table: Quantizing document length into a 1-byte fieldnorm replaces expensive per-document floating-point math with a single array lookup.

Retrieval Accuracy Benchmark (`NDCG@10` on BEIR & LoTTE)

The table below (from our BEIR / LoTTE Hybrid Search & ColBERT Reranking evaluation) compares retrieval accuracy (NDCG@10) across:

Benchmark with pgvector

Mon, 01 Jan 0001 00:00:00 +0000

In this section, we compare VectorChord with pgvector, a PostgreSQL extension that provides vector similarity search capabilities. We will focus on four key metrics: QPS (Queries Per Second), Recall@100, Index Building Time, and Insertion Time. If you are interested in the details of our implementation, please refer to our blog Vector Search Over PostgreSQL: A Comparative Analysis of Memory and Disk Solutions.

QPS & Recall

Here are some initial benchmark results for the GIST dataset, which consists of 1 million vectors in 960 dimensions. With equivalent recall, VectorChord’s QPS could be twice that of pgvector. More details will be provided in the Benchmark section.

Citus

Mon, 01 Jan 0001 00:00:00 +0000

citus is a PostgreSQL extension that turns Postgres into a distributed database. pgvecto.rs works well with citus Here are the steps to enable vector search in a distributed PostgreSQL instance.

citus can works on Single-Node and Multi-Node, both of which are compatible with pgvecto.rs natively.

Single-Node Citus

First, prepare the dockerfile with pgvecto.rs and citus installed and attach them to PostgreSQL.

Details

citus must be placed first in shared_preload_libraries due to its restrictions.

Clusters

Mon, 01 Jan 0001 00:00:00 +0000

One or more clusters can be created in a project. A cluster is a collection of nodes that run a Postgres cluster.

Create a cluster

To create a new cluster, navigate to the VectorChord Cloud Console and click on the “Create Cluster” button.

You need to specify the following information:

Required:
- Plan: The plan you want to use for your cluster, for information about Cloud’s paid plan options, see Cloud plans.
- Cluster Name: A unique name for your cluster.
- Extension Settings:
  - Extension: We support two Vector Search extensions, pgvectors and its successor vectorchord
    - vectorchord: Scalable, Fast, and Disk-friendly Vector search in Postgres
    - pgvectors: Scalable, Low-latency and Hybrid-enabled Vector Search in Postgres. Revolutionize Vector Search, not Database.
    Warning
    
    The vectorchord only support server resource with NVMe SSD.
  - Image:
    - VectorChord, we provide a tag in a semantic version format, for example 16-v0.1.0:
      - 16 indicates the version number of Postgres major
      - v0.1.0 indicates VectorChord version number
    - pgvecto.rs, we provide a tag in a semantic version format, for example 16-v0.4.0-vectors-exts:
      - 16 indicates the version number of Postgres major
      - v0.4.0 indicates pgvecto.rs version number
      - vectors indicates the installation location of pgvecto.rs scheme, optional vectors,extensions, public. Please choose public if you want to use VectorChord Cloud on AWS RDS. If you’re going to use fdw on Supabase, please choose extensions.
      - exts indicates the cluster can install extensions from https://pgt.dev/.
- Cloud Provider Settings:
  - Cloud Provider: The cloud provider where your cluster will be deployed, currently only AWS is supported.
  - Region: The region where your cluster will be deployed.
- Resource Settings:
  - Type: We provide two types of resources, Performance and Capacity.
  - Server Resource:
    - Performance:
      - 1C/2G: Free tier, 1 core CPU, 2GB memory and 3Gi disk space.
      - 2C/8G: Enterprise tier, 2 core CPU, 8GB memory and 15Gi disk space.
      - 2C/16G: Enterprise tier, 2 core CPU, 16GB memory and 15Gi disk space.
      - 4C/32G: Enterprise tier, 4 core CPU, 32GB memory and 90Gi disk space.
    - Capacity:
      - 4C/32G NVMe SSD: Enterprise tier, 4 core CPU, 32GB memory and 850Gi NVMe SSD disk space.
- Postgres Settings:
  - Database Name: The name of the database that you will store vector data in.
  - Enable Connection Pooler: (default: false): Enable the connection pooler for your cluster.
  - Enable Restore Config: (default: false): Enable the restore config for your backup created in other clusters.
  - Optional:
    - Disk Size: Postgres PGData disk size, will change the default disk size.
    - Instances: The number of instances in the cluster. The default is 1.
    Warning
    
    Currently, vector index not support streaming replication.

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

Mon, 01 Jan 0001 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?

Filtered Search & Prefiltering

Mon, 01 Jan 0001 00:00:00 +0000

Real-world applications frequently combine full-text BM25 ranking with structured relational filters (such as category_id = 5, tenant_id = 'acme', or date ranges). vchord_bm25 supports three strategies for filtered BM25 search.

1. Post-Filtering vs. Pre-Filtering

When you execute a query with a WHERE clause and ORDER BY embedding <&> to_bm25query(...) LIMIT K:

SELECT id, passage
FROM documents
WHERE category = 'database'
ORDER BY embedding <&> to_bm25query('documents_embedding_bm25', tokenize('PostgreSQL BM25', 'my_tokenizer'))
LIMIT 10;

There are two ways vchord_bm25 can evaluate the WHERE predicate:

Graph Index

Mon, 01 Jan 0001 00:00:00 +0000

since v0.5.0

VectorChord’s index type vchordg is a disk-based graph index. It has low memory consumption.

Let’s start by creating a table named items with an embedding column of type vector(n), and then populate it with sample data.

To create a vchordg index, you can use the following SQL.

CREATE INDEX ON items USING vchordg (embedding vector_l2_ops);

Tip

This feature is in preview.

Image Search

Mon, 01 Jan 0001 00:00:00 +0000

Image intelligent search, also known as content-based image retrieval, goes beyond traditional keyword-based search and enables users to search for images based on their visual content. For example, you could search images that contain a red mushroom (image from immich):

The feature looks like a magic because it allows you to search for images that you don’t have keywords for. The search engine understands the content of the images and videos and can find the ones that are similar to the query.

Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

If you want to use vectorchord in PostgreSQL which is running in Kubernetes, we provide a tutorial to help you. In this tutorial, we will use CloudNative-PG to deploy PostgreSQL cluster in Kubernetes.

Requirements

Name	Version
helm	>= 2.4.1
kubectl	>= 1.14
Kubernetes	>= 1.24.0
Kubernetes (Image Volume Extensions)	>= 1.31.0

Install CloudNative-PG

We use CloudNative-PG (cnpg) to deploy PostgreSQL cluster in Kubernetes. You can install it by helm.

Logical replication

Mon, 01 Jan 0001 00:00:00 +0000

Logical replication is a feature in PostgreSQL that enables the replication of individual database objects or a subset of data from one PostgreSQL database to another.

With logical replication, you can selectively replicate specific tables, databases, or even specific rows based on predefined replication rules. This provides more flexibility compared to physical replication, where the entire database cluster is replicated. It allows you to design custom replication topologies and replicate only the data that is necessary for your use case.

Monitoring

Mon, 01 Jan 0001 00:00:00 +0000

We provide a view pg_vector_index_stat to monitor the progress of indexing.

Column	Type	Description
tablerelid	oid	The oid of the table.
indexrelid	oid	The oid of the index.
tablename	name	The name of the table.
indexname	name	The name of the index.
idx_status	text	Its value is `NORMAL` or `UPGRADE`. Whether this index is normal or needs upgrade.
idx_indexing	bool	Not null if `idx_status` is `NORMAL`. Whether the background thread is indexing.
idx_tuples	int8	Not null if `idx_status` is `NORMAL`. The number of tuples.
idx_sealed	int8[]	Not null if `idx_status` is `NORMAL`. The number of tuples in each sealed segment.
idx_growing	int8[]	Not null if `idx_status` is `NORMAL`. The number of tuples in each growing segment.
idx_write	int8	Not null if `idx_status` is `NORMAL`. The number of tuples in write buffer.
idx_size	int8	Not null if `idx_status` is `NORMAL`. The byte size for all the segments.
idx_options	text	Not null if `idx_status` is `NORMAL`. The configuration of the index.

idx_options Details

The idx_options is a JSON string that includes vector, segment, optimization, and indexing options. Examples below:

{
    "vector": {
        "dimensions": 256,
        "distance": "L2",
        "kind": "F32"
    },
    "segment": {
        "max_growing_segment_size": 20000,
        "max_sealed_segment_size": 1000000
    },
    "optimizing": {
        "sealing_secs": 60,
        "sealing_size": 1,
        "delete_threshold": 0.2,
        "optimizing_threads": 2
    },
    "indexing": {
        "hnsw": {
            "m": 12,
            "ef_construction": 300,
            "quantization": {
                "trivial": {}
            }
        }
    }
}

Why not a specialty vector database?

Mon, 01 Jan 0001 00:00:00 +0000

Read our complete blog at Do we really need a specialized vector database? (2023) | vchord.pgsty.com.

Imagine this, your existing data is stored in a Postgres database, and you want to use a vector database to do some vector similarity search. You have to move your data from Postgres to the vector database, and you have to maintain two databases at the same time. This is not a good idea.

Why not just use Postgres to do the vector similarity search? This is the reason why we build pgvecto.rs. The user journey is like this:

Quick Start

Mon, 01 Jan 0001 00:00:00 +0000

This guide walks through creating a table, tokenizing documents, building a bm25 index, and executing Top-K BM25 queries.

Workflow A: `bm25vector` + `pg_tokenizer` (`v0.1` – `v0.3`)

In released versions v0.1.0 through v0.3.0, vchord_bm25 pairs with pg_tokenizer to tokenize text into a bm25vector column.

1. Enable Extensions and Configure `search_path`

CREATE EXTENSION IF NOT EXISTS pg_tokenizer CASCADE;
CREATE EXTENSION IF NOT EXISTS vchord_bm25 CASCADE;

SET search_path TO "$user", public, bm25_catalog, tokenizer_catalog;

2. Create a Tokenizer

Use create_tokenizer with the built-in llmlingua2 (or bert_base_uncased) model:

Search Options

Mon, 01 Jan 0001 00:00:00 +0000

Search options are specified by PostgreSQL GUC.

Options for `ivf`

These options only work for IVF algorithm. Refer to Indexing.

Option	Type	Range	Default	Description
vectors.ivf_nprobe	integer	`[1, 1_000_000]`	`10`	Number of lists to scan.

Options for `hnsw`

These options only work for HNSW algorithm. Refer to Indexing.

Option	Type	Range	Default	Description
vectors.hnsw_ef_search	integer	`[1, 65535]`	`100`	Search scope of HNSW.

Other Options

Query options for search mode: .

Sparse Vector: `svector`

Mon, 01 Jan 0001 00:00:00 +0000

since v0.3.0

Unlike dense vectors, sparse vectors are very high-dimensional but contain few non-zero values.

Typically, sparse vectors can be created from:

Word co-occurrence matrices
Term frequency-inverse document frequency (TF-IDF) vectors
User-item interaction matrices
Network adjacency matrices

Sparse vectors in pgvecto.rs are called svector.

Here’s an example of creating a table with a svector column and inserting values:

CREATE TABLE items (
  id bigserial PRIMARY KEY,
  embedding svector(10) NOT NULL
);

INSERT INTO items (embedding) VALUES ('[0.1,0,0,0,0,0,0,0,0,0]'), ('[0,0,0,0,0,0,0,0,0,0.5]');

Index can be created on svector type as well.

Tokenization Models

Mon, 01 Jan 0001 00:00:00 +0000

In pg_tokenizer, a Model maps string tokens (or raw text) to integer token IDs (INT[]). You can choose from four built-in pretrained models, train a custom vocabulary model directly on your PostgreSQL table, import any HuggingFace tokenizer.json, or use a Lindera morphological model.

1. Built-in Pretrained Models

Model Name	Source / Architecture	Requires `text_analyzer`?	Memory Footprint	Best For
`llmlingua2`	`microsoft/llmlingua-2-xlm-roberta-large-meetingbank` (XLM-RoBERTa multilingual subword)	No (forbidden)	~200 MB (default preloaded)	Multilingual general text out of the box without training a custom vocabulary.
`bert_base_uncased`	`google-bert/bert-base-uncased` (WordPiece, 30,522 vocab)	No (forbidden)	~15 MB	General English text; fast startup and compact vocabulary.
`wiki_tocken`	`Snowolf/wiki-tocken` (Built-in English Wikipedia token dictionary)	Yes (required)	~30 MB	English full-text search combined with custom stemmers, stopwords, and synonyms.
`gemma2b`	`google/gemma-2b` (SentencePiece BPE, 256k vocab)	No (forbidden)	~100 MB	Code, technical identifiers, and multilingual LLM workloads.

Example: Using `bert_base_uncased` or `llmlingua2`

SELECT create_tokenizer('bert_tok', $$
model = "bert_base_uncased"
$$);

SELECT tokenize('VectorChord-BM25 brings Block-WeakAnd to PostgreSQL.', 'bert_tok');

2. Custom Corpus Models (`create_custom_model`)

For maximum BM25 accuracy and minimal memory footprint, you can build a custom vocabulary model directly from your own table column. Unlike subword LLM tokenizers (which split rare domain words into multiple sub-tokens), a custom model assigns a dedicated 1:1 integer ID to every unique normalized token produced by your text_analyzer—and weighs only a few megabytes in memory.

Trademark Policy

Mon, 01 Jan 0001 00:00:00 +0000

Statement of Independence

pgsty/vchord and vchord.pgsty.com are maintained by the Pigsty community. Neither pgsty/vchord nor vchord.pgsty.com is affiliated with, endorsed by, or sponsored by TensorChord Inc.

Third-Party Trademarks

VectorChord, pgvecto.rs, and TensorChord are names and marks associated with TensorChord Inc. They are used on this site solely for nominative fair use to identify the upstream open-source projects, extension names (vchord, vectors), SQL access methods (vchordrq, vchordg), and historical engineering articles.
PostgreSQL and Postgres are registered trademarks of the PostgreSQL Community Association of Canada.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Amazon Web Services (AWS), Cloudflare, Docker, and other product or company names referenced in benchmarks and deployment guides are trademarks of their respective owners.

Vchord Suite

Mon, 01 Jan 0001 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.

Authorization

Mon, 01 Jan 0001 00:00:00 +0000

Topics related to role-based access control (RBAC) on your VectorChord Cloud clusters.

User Roles

We provide two types of roles for the project: Owner and Member.

Owner: The owner has full access to the project. The owner can invite members, create or delete clusters, and view the billing information.
Member: The member has read-only access to the project. The member can view the cluster information, but cannot create or delete clusters.

API Key Roles

API Key provide more fine-grained control over access to resources by assigning roles with specific permissions to users within the projects. We provide two types of roles for the API Key: Owner and Member.

Benchmarks

Mon, 01 Jan 0001 00:00:00 +0000

pgvecto.rs has been focused on performance from the beginning. We have continuously monitored the performance of pgvecto.rs and compared it with other vector search libraries. The following benchmark results are from January 2024.

The test is done on Google Cloud n2-standard-8 (8 vCPUs, 32 GB RAM) with the laion-768-5m-ip dataset.

`pgvecto.rs` v.s. `pgvector`

With the HNSW index, pgvecto.rs can achieve 2.5x responses per second as pgvector can do with a slightly better precision of around 97%. This advantage increases when higher precision is required.

Benchmark with Elasticsearch

Mon, 01 Jan 0001 00:00:00 +0000

Here we present a comprehensive benchmark comparing our implementation of VectorChord-BM25 with ElasticSearch, focusing on two key metrics: QPS (Queries Per Second) and NDCG@10 (Normalized Discounted Cumulative Gain at rank 10). If you are interested in the details of our implementation, please refer to our blog VectorChord-BM25: Revolutionize PostgreSQL Search with BM25 Ranking — 3x Faster Than ElasticSearch.

RPS

We compare the Top1000 Queries Per Second (QPS)—a metric that measures how many queries a system can process per second while retrieving the top 1000 results for each query—between our implementation and ElasticSearch across various datasets from bm25-benchmarks. On average, our implementation achieves 3 times higher QPS compared to ElasticSearch across the tested datasets, showcasing its efficiency and scalability.

Binary Vector: `bvector`

Mon, 01 Jan 0001 00:00:00 +0000

since v0.3.0

The bvector type is a binary vector type in pgvecto.rs. It represents a binary vector, which is a vector where each component can take on two possible values, typically 0 and 1.

Here’s an example of creating a table with a bvector column and inserting values:

CREATE TABLE items (
  id bigserial PRIMARY KEY,
  embedding bvector(3) NOT NULL
);

INSERT INTO items (embedding) VALUES ('[1,0,1]'), ('[0,1,0]');

Index can be created on bvector type as well.

Foreign data wrapper (FDW)

Mon, 01 Jan 0001 00:00:00 +0000

Foreign data wrapper(FDW) is an extension in PostgreSQL that allows you to access and query data stored in remote databases as if they were local tables. FDW provides a way to integrate and interact with different data sources.

With the FDW extension, you can define foreign tables in your local PostgreSQL database that mirror the structure of tables in remote databases. These foreign tables act as proxies or wrappers for the remote data, enabling you to perform SELECT, INSERT, UPDATE, and DELETE operations on them, just like regular tables in PostgreSQL.

Hybrid Search (BM25 + VectorChord)

Mon, 01 Jan 0001 00:00:00 +0000

Modern retrieval pipelines combine dense vector search (vchord, which captures semantic similarity) with sparse lexical BM25 search (vchord_bm25, which captures exact keyword, identifier, and rare-term matches). Because both extensions run natively inside PostgreSQL, you can execute end-to-end hybrid search in a single SQL query with zero external orchestration.

Schema Setup for Hybrid Search

CREATE EXTENSION IF NOT EXISTS vchord CASCADE;
CREATE EXTENSION IF NOT EXISTS pg_tokenizer CASCADE;
CREATE EXTENSION IF NOT EXISTS vchord_bm25 CASCADE;

SET search_path TO "$user", public, bm25_catalog, tokenizer_catalog;

-- 1. Create a BM25 tokenizer
SELECT create_tokenizer('bert', $$
model = "bert_base_uncased"
$$);

-- 2. Create a table storing both dense vectors and sparse bm25vectors
CREATE TABLE chunks (
    id SERIAL PRIMARY KEY,
    content TEXT NOT NULL,
    dense_emb vector(768),
    bm25_emb bm25vector
);

-- 3. Create VectorChord dense index (vchordrq) and BM25 lexical index (bm25)
CREATE INDEX chunks_dense_idx ON chunks USING vchordrq (dense_emb vector_l2_ops);
CREATE INDEX chunks_bm25_idx  ON chunks USING bm25 (bm25_emb bm25_ops);

Method 1: Reciprocal Rank Fusion (RRF) in Pure SQL

Reciprocal Rank Fusion (RRF) combines rankings from multiple retrieval systems without requiring score calibration between L2/cosine distance and BM25 scores:

Multi Tenancy

Mon, 01 Jan 0001 00:00:00 +0000

Multi-tenancy is essential for SaaS applications, allowing a single instance to serve multiple users or groups while ensuring data privacy and security. This blog outlines the design and implementation a simple multi-tenant vector search system with pgvecto.rs.

Designing the Database Schema

The success of user-based isolation in multi-tenant systems hinges on a well-structured database schema:

Users and Documents

Each user is identified by a unique user_id, which directly links them to their documents for private access. The documents table contains each user’s documents, each with a distinct id, title, and content. Additional metadata can be included in the documents table to improve search functionality. The user_id is linked to the documents instead of chunk embeddings to replicate real-world scenarios more accurately.

Multilingual Recipes & Limitations

Mon, 01 Jan 0001 00:00:00 +0000

This page provides production-ready tokenization recipes for English, Chinese, and Japanese full-text BM25 search, followed by important operational limitations to keep in mind.

Recipe 1: English with Stemming & Stopwords (`wiki_tocken`)

Combines Unicode word segmentation, NLTK stopwords removal, and Porter2 stemming with the built-in Wikipedia vocabulary (wiki_tocken):

SELECT create_tokenizer('eng_wiki', $$
model = "wiki_tocken"

[text_analyzer.character_filters.to_lowercase]
[text_analyzer.pre_tokenizer.unicode_segmentation]
[[text_analyzer.token_filters.skip_non_alphanumeric]]
[[text_analyzer.token_filters.stopwords]]
words = "nltk_english"
[[text_analyzer.token_filters.stemmer]]
kind = "english_porter2"
$$);

SELECT tokenize('PostgreSQL databases are running analytical and vector workloads.', 'eng_wiki');

Recipe 2: English Custom Corpus Model with Trigger

From the upstream pg_tokenizer examples, this workflow builds a domain-specific English vocabulary from your documents table and keeps embeddings updated automatically via trigger:

Quantization

Mon, 01 Jan 0001 00:00:00 +0000

Quantization is a technique to reduce the memory consumption and computation complexity with the affordable decrease in precision. In the context of vector search, there are mainly two types of quantization: production quantization and scalar quantization.

Production Quantization

Production quantization is a method that trains several clustering models on the dataset and maps each vector to a list of cluster center indexes. It is commonly used address the problem of excessive memory usage with high-dimensional data.

Quantization Types

Mon, 01 Jan 0001 00:00:00 +0000

since v1.1.0

Quantization can be applied not only to indexes but also directly to vectors. To this end, VectorChord provides data types for quantized vectors.

rabitq8 is the data type of a quantized vector. For the same dimension, its cost is about $\frac{1}{4}$ that of a full-precision vector (vector) and $\frac{1}{2}$ that of a half-precision vector (halfvec). This type is named after its quantization algorithm.¹

Release History & API Evolution

Mon, 01 Jan 0001 00:00:00 +0000

This page tracks the release history and SQL schema evolution of vchord_bm25 (pgsty/vchord_bm25 / supervc-stack/VectorChord-bm25).

Version Summary Matrix

Version	Schema	Indexed Type	Tokenizer	Key Additions
`main` (Next-Gen)	Extension schema	`tsvector`	Native `to_tsvector` (or custom)	Complete storage & index engine rewrite on native `tsvector`; external sort parallel `ambuild`; index reloptions (`options`, `limit`, `prefilter`); `bm25.*` GUCs; PostgreSQL 18 support.
`v0.3.0`	`bm25_catalog`	`bm25vector`	`pg_tokenizer`	Added `bm25_page_inspect(regclass, int)`, `to_bm25query(regclass, int[])` overload, and PostgreSQL 18 compatibility.
`v0.2.2`	`bm25_catalog`	`bm25vector`	`pg_tokenizer`	Added `bm25_catalog.enable_prefilter` GUC for accurate filtered Top-K BM25 search with `WHERE` clauses.
`v0.2.1`	`bm25_catalog`	`bm25vector`	`pg_tokenizer`	Bug fixes for growing/sealed segment transitions and vacuum cleanup.
`v0.2.0`	`bm25_catalog`	`bm25vector`	`pg_tokenizer`	Added `=` and `<>` equality operators on `bm25vector` and implicit cast `CREATE CAST (int[] AS bm25vector) AS IMPLICIT`.
`v0.1.1`	`bm25_catalog`	`bm25vector`	`pg_tokenizer`	Decoupled tokenization into standalone `pg_tokenizer` extension; changed `to_bm25query(regclass, bm25vector)` signature.
`v0.1.0`	`bm25_catalog`	`bm25vector`	Built-in `unicode`	Initial release with `bm25vector`, `bm25query`, `USING bm25`, and Block-WeakAnd Top-K scan.

Detailed Upgrade Changes

`v0.3.0` (`sql/vchord_bm25--0.2.2--0.3.0.sql`)

Added page diagnostic function:

CREATE FUNCTION bm25_page_inspect(index regclass, blkno INT) RETURNS TEXT;

Added to_bm25query(regclass, int[]) convenience overload in main/late 0.3.x.

`v0.2.2` (`sql/vchord_bm25--0.2.1--0.2.2.sql`)

Added prefiltering support in Block-WeakAnd (bm25_catalog.enable_prefilter GUC, enabled by default in 0.3.0).
Improved MVCC visibility checking during index scans to prevent dead/filtered tuples from polluting the Top-K threshold.

`v0.2.0` (`sql/vchord_bm25--0.1.1--0.2.0.sql`)

Added = and <> operators for bm25vector.
Added implicit cast from int[] to bm25vector (_vchord_bm25_cast_array_to_bm25vector), allowing tokenize(text, name) output (INT[]) to be assigned or passed directly wherever bm25vector is expected.

`v0.1.1` (`sql/vchord_bm25--0.1.0--0.1.1.sql`)

Extracted built-in create_tokenizer / tokenize functions into the dedicated pg_tokenizer extension (tokenizer_catalog), enabling rich text analyzers, Snowball stemmers, stopwords, synonyms, HuggingFace models, jieba, and lindera.
Simplified to_bm25query(index_oid regclass, query_vector bm25vector) to accept a bm25vector directly.

Next-Generation Rewrite (`main` Branch)

Replaced custom bm25vector with PostgreSQL’s native tsvector (CREATE OPERATOR CLASS bm25_ops FOR TYPE tsvector USING bm25), allowing users to index to_tsvector(...) columns directly with USING bm25.
Added parallel index build (bm25_parallel_build_main) with external merge sort and constant maintenance memory consumption.
Added configurable BM25 hyperparameters ( $k_1 \in [1.2, 2.0]$ , $b \in [0.0, 1.0]$ ) via WITH (options = $$ k1 = 1.2, b = 0.75 $$).

Backup & Restore

Mon, 01 Jan 0001 00:00:00 +0000

Database backups are an integral part of any disaster recovery plan. Disasters come in many shapes and sizes. It could be as simple as accidentally deleting a table column, the database crashing, or even a natural calamity wiping out the underlying hardware a database is running on. The risks and impact brought by these scenarios can never be fully eliminated, but only minimized or even mitigated. Having database backups is a form of insurance policy. They are essentially snapshots of the database at various points in time. When disaster strikes, database backups allow the project to be brought back to any of these points in time, therefore averting the crisis.

Benchmark with pgvectorscale

Mon, 01 Jan 0001 00:00:00 +0000

In this section, we compare VectorChord with pgvectorscale, a PostgreSQL extension that provides vector similarity search capabilities. We will focus on four key metrics: QPS (Queries Per Second), Recall@10/100, Index Building Time, and Insertion Time. Memory and disk performance will also be discussed. If you are interested in the details of our implementation, please refer to our blog Vector Search Over PostgreSQL: A Comparative Analysis of Memory and Disk Solutions.

QPS & Recall

BM25 & Block-WeakAnd Internals

Mon, 01 Jan 0001 00:00:00 +0000

This page details the exact scoring equations and data structures implemented in vchord_bm25 (crates/bm25/src/bm25.rs and src/algorithm/block_wand.rs).

1. Okapi BM25 Scoring Formula

Given a document $D$ and a query $Q = \\{q_1, q_2, \\dots, q_m\\}$ with query term frequencies $c(q_i, Q)$ and document term frequencies $f(q_i, D)$ , vchord_bm25 computes:

`pgvector` compatibility

Mon, 01 Jan 0001 00:00:00 +0000

pgvecto.rs is natively compatible with pgvector at:

CREATE TABLE commands, e.g. CREATE TABLE t (val vector(3))
INSERT INTO commands, e.g. INSERT INTO t (val) VALUES ('[0.6,0.6,0.6]')

pgvecto.rs can be configured to be compatible with pgvector at:

Index options, which allows you to create index by USING hnsw (val vector_ip_ops)
Query options, which can be set by SET ivfflat.probes = 10

This feature is named pgvector compatibility. It can be enabled by SET vectors.pgvector_compatibility = on.

Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

If you want to use pgvecto.rs in PostgreSQL which is running in Kubernetes, we provide a tutorial to help you. In this tutorial, we will use CloudNative-PG to deploy PostgreSQL cluster in Kubernetes.

Requirements

Name	Version
helm	>= 2.4.1
kubectl	>= 1.14
Kubernetes	>= 1.24.0

Install CloudNative-PG

We use CloudNative-PG (cnpg) to deploy PostgreSQL cluster in Kubernetes. You can install it by helm.

Similarity Filter

Mon, 01 Jan 0001 00:00:00 +0000

Usually, ORDER BY and LIMIT clauses are used to perform vector search. In some cases, you may want to use a WHERE clause to filter out vectors that are far from the query. Naturally, you might write the following SQL.

EXPLAIN (COSTS FALSE) 
SELECT * FROM items WHERE embedding <-> '[0, 0, 0]' < 0.1 ORDER BY embedding <-> '[0, 0, 0]' LIMIT 10;
                                  QUERY PLAN                                   
-------------------------------------------------------------------------------
 Limit
   ->  Index Scan using items_embedding_idx on items
         Order By: (embedding <-> '[0,0,0]'::vector)
         Filter: ((embedding <-> '[0,0,0]'::vector) < '0.1'::double precision)

The returned results meet expectations, while this approach suffers from poor performance. This is because if fewer than $10$ vectors fall within the distance threshold, PostgreSQL forces the index to continue to search to get $10$ results, exhausting the entire search space.

Sparse Vector Search

Mon, 01 Jan 0001 00:00:00 +0000

In the past, hybrid search combined two search methods: traditional keyword-based search and vector-based similarity search. However, sparse vector can act as a substitute for keyword search, unlocking the full potential of the data pipeline with pure vector search.

Tip

For more information about keyword-based hybrid search, please refer to Hybrid Search

This post explores how to use how BGE-M3 and pgvecto.rs to exploit the potential of hybrid search using both sparse and dense vectors.

Generative Question-Answering

Mon, 01 Jan 0001 00:00:00 +0000

Vector search can also be used to provide context to generative models such as OpenAI’s GPT series, improving the quality of the outputs.

This post will explore the use of pgvecto.rs in building and retrieving from a vector knowledge base to bolster the performance of generative models in question-answering tasks. A knowledge base serves as “long-term memory” for generative models, providing them persistent, curated, and accurate information as context to draw from when generating an answer to a question. This results in answers that are more accurate, reduces the possibility of the model producing “hallucinations” (statements with no basis in reality), and increases user trust in the outputs. This technique is known as Retrieval-Augmented Generation, or RAG: see this post or the related paper for more information.

Migration

Mon, 01 Jan 0001 00:00:00 +0000

outline: [2,3]

PGVecto.rs Migration Overview

From pgvector

Prerequisites

When migrating from pgvector to PGVecto.rs, it is possible that you may have a table with a column of vector type. An example of this would be:

CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(3));

In addition, some rows will be inserted into the table, as follows:

PostgreSQL Tuning

Mon, 01 Jan 0001 00:00:00 +0000

Indexing may be parallelized. Parallelism increases server load and is therefore not enabled by default in PostgreSQL. To enable it, refer to the following SQL.

-- Sets the maximum number of background processes that the cluster can support.
-- It's recommended to set it to at least the sum of your desired parallelism plus 8.
-- For example, if you want to use 16 threads for parallel processing, set the value at least to 24.
-- Depending on your workload, this value might be useful to be higher.
-- Note: A restart is required for this setting to take effect.
ALTER SYSTEM SET max_worker_processes = 24;

-- Sets the maximum number of workers that the cluster can support for parallel operations.
-- It's recommended to set it to the sum of your desired parallelism minus 1.
-- For example, if you want to use 16 threads for parallel processing, set the value to 15.
SET max_parallel_workers = 15;

-- Sets the maximum number of parallel workers that can be started by a single utility command.
-- It's recommended to set it to the sum of your desired parallelism minus 1.
-- For example, if you want to use 16 threads for parallel processing, set the value to 15.
SET max_parallel_maintenance_workers = 15;

The number of parallel workers also depends on the table’s configuration. By default, this is automatically determined by PostgreSQL. If PostgreSQL identifies it as disabled, parallel indexing will not take effect. You can override PostgreSQL’s behavior by adjusting the table’s parallel_workers setting to enable parallel indexing.

Upgrade

Mon, 01 Jan 0001 00:00:00 +0000

You may need to upgrade your cluster and do not want to lose any data. You can upgrade the server resource like CPU, memory. Or you only want to upgrade the storage. The following sections will guide you through the process of upgrading your cluster.

Increasing server resource

If you want to increase the server resource like CPU and memory, the status of the cluster need to be Ready. And click the Upgrade button in the cluster detail page.

API Keys

Mon, 01 Jan 0001 00:00:00 +0000

On VectorChord Cloud, every project comes with a set of API keys. These keys are essential authentication tokens required for initiating terraform operations.

Role-based Access Control (RBAC)

Role-based Access Control (RBAC) is a crucial security mechanism in VectorChord Cloud, applicable to managing API calls. This system allows for fine-grained control over access to resources by assigning roles with specific permissions to users within the projects.

Monitoring

Mon, 01 Jan 0001 00:00:00 +0000

You can monitor the progress of building a PostgreSQL index by querying the pg_stat_progress_create_index view.

SELECT command, phase, round(100.0 * blocks_done / nullif(blocks_total, 0), 1) AS "%" FROM pg_stat_progress_create_index;

Reference

Phases (`vchordrq`)

vchordrq

There are 5 steps in the index construction process of vchordrq. The phase name of each step are as follows:

Fallback Parameters

Mon, 01 Jan 0001 00:00:00 +0000

since v1.1.0

Search parameters are typically configured via GUCs. VectorChord also offers an alternative method, allowing these parameters to be attached directly to an index instead of a session or transaction. In other words, you can store them as part of the index’s storage parameters.

You could set probes at index building using the following syntax.

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

You can now perform searches without setting GUCs:

Terraform Integration Overview with VectorChord Cloud

Mon, 01 Jan 0001 00:00:00 +0000

This guide walks you through the process of installing and configuring the PGVecto.rs Cloud provider.

1. Prerequisites

Before you begin, ensure you have the following:

Terraform Installed: Download and install Terraform from here by following the provided instructions.
VectorChord Cloud Account: Access to VectorChord Cloud and your API Key are essential. Go to the VectorChord Cloud Console and create an API key. The API key must have the ProjectOwner permissions. For more information, see API Key.

Measure Recall

Mon, 01 Jan 0001 00:00:00 +0000

since v0.5.0

In the context of vector search, recall is the ratio of true nearest neighbors to approximate nearest neighbors returned by the index. For example, if the index retrieves $100$ approximate nearest neighbors and $97$ of them are true nearest neighbors, then the recall is $\frac{97}{100} = 0.97$ .

Tip

This feature is in preview.

Regions

Mon, 01 Jan 0001 00:00:00 +0000

Deploying to Regions

With VectorChord Cloud, you can deploy clusters to different Regions. When creating an cluster, pick a Region using the drop-down selector.

Tip

Don’t see the Region or Provider that you want? Please contact us at Discord, we are happy to help.

Prewarm

Mon, 01 Jan 0001 00:00:00 +0000

After PostgreSQL starts, tables and indexes are loaded from storage into the buffer pool only when they are accessed for the first time. As queries are executed, the frequently accessed parts of the index are naturally cached in the buffer pool. However, as initial queries are executed, the buffer pool is empty, which causes the queries to be slow.

The PostgreSQL extension pg_prewarm includes the pg_prewarm function, which can partially address this issue. After PostgreSQL starts, you simply provide the name of the index to this function, and it will load the index from storage into the buffer pool.

Workflow

Mon, 01 Jan 0001 00:00:00 +0000

Overview

Workflow is a feature that allow you can use some pre-defined functions to complete some tasks. For example, you can use ExternalBuildIndex workflow to build index externally for your Postgres cluster. There are some advantages of using workflow:

Out Of Box: You can use the pre-defined functions to complete some tasks without writing any code.
Accelerate Tasks: You can use a server with a higher resource configuration than the PostgreSQL cluster to accelerate the task.
Cluster Stability: The workflow is executed in a separate server, which will not affect the stability of the PostgreSQL cluster.
Low Cost: You do not need to pay continuously like a database for high configuration resources for short-term tasks.

Supported Workflows

Supported workflows are as follows:

Prefilter

Mon, 01 Jan 0001 00:00:00 +0000

since v0.4.0

In a filtered index scan, the index performs the scan first and then PostgreSQL checks whether the filter conditions are satisfied. On this page, “filter” refers to the filter on the index scan node of the query plan in PostgreSQL. This is usually constructed from the WHERE clause in the SQL statement. The filter does not need to have a specific form.

EXPLAIN (COSTS FALSE)
SELECT * FROM items WHERE id <= 5000 AND vector_norm(embedding) < 0.5;
                          QUERY PLAN                          
--------------------------------------------------------------
 Index Scan using items_pkey on items
   Index Cond: (id <= 5000)
   Filter: (vector_norm(embedding) < '0.5'::double precision)

However, this is not always the most efficient approach for vector search. Consider the following query.

Prefetch

Mon, 01 Jan 0001 00:00:00 +0000

since v0.4.0

Prefetch dramatically accelerates queries that involve I/O operations. It works by proactively reading buffers into operating system page cache or PostgreSQL’s buffer pool based on the actual needs of the index.

Prefetch helps overlap I/O with computation, as well as I/O with other I/O operations, significantly reducing the time spent waiting for buffers during query execution, thereby improving overall query performance.

Tip

This feature is enabled by default. Any query can benefit from prefetching with VectorChord 0.4.0 and later versions.

Rerank in Table

Mon, 01 Jan 0001 00:00:00 +0000

since v0.2.1

PostgreSQL indexes store row identifiers and the values of the indexed columns. Typically, indexed columns have simple data types, for example, integers or strings with short length limits.

However, if the indexed column is of a vector type, both the table and the index store vectors, which means you pay twice the storage cost for the vectors. If you would like to reduce this cost, you can enable rerank_in_table when building the index. The index will then use a tricky approach where it does not store the vectors itself but reads them from the table when needed.

Partitioning Tuning

Mon, 01 Jan 0001 00:00:00 +0000

For large tables, the partitioning phase dominates both build time and memory consumption.

Time complexity of partitioning is $O(FC^{2}DL)$ , and the memory consumption in bytes can be approximated by $4DC(F + T + 1)$ ,

where:

$D$ is the vector dimension, or build.internal.kmeans_dimension if set.
$F$ is build.internal.sampling_factor.
$C$ is build.internal.lists[-1].
$T$ is build.internal.build_threads.
$L$ is build.internal.kmeans_iterations.

This page introduces some tuning techniques to improve build time and memory consumption.

External Build

Mon, 01 Jan 0001 00:00:00 +0000

In addition to using the methods in Partitioning Tuning to achieve shorter build time and lower memory consumption at the cost of QPS and recall, you can also choose to run the partitioning phase offline on other machines or on GPUs. This feature is not supported by vchordg, since it does not have a partitioning phase.

Assume the table is t and the column to be indexed is val.

CREATE TABLE t (val vector(3));

Specifically, you need to sample the column for which the index will be built.

Page Not Found

Mon, 01 Jan 0001 00:00:00 +0000

The page you are looking for has moved, been deleted, or does not exist. Use the search bar (⌘K) or return to the VectorChord Documentation.

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.

Scaling Vector Search to 1 Billion on PostgreSQL

Thu, 15 Jan 2026 00:00:00 +0000

For teams trying to run vector search at billion scale themselves, the challenge is often not raw performance, but practicality. Many solutions designed for billion-scale, low-latency vector search come with practical constraints, requiring tradeoffs that affect how easily they can be adopted.

Most existing approaches fall into one of a few categories:

Operationally complex: Powered by multi-node distributed system that are difficult to manage, operate, and maintain over time.
Build-time prohibitive: Requiring long index build times, which makes re-indexing costly and easily impacts production workloads.
Memory heavy: Depending on up to 1 TB of memory on a single machine, making the hardware significantly less affordable for most teams.

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.

How We Made 100M Vector Indexing in 20 Minutes Possible on PostgreSQL

Wed, 03 Dec 2025 00:00:00 +0000

1. Introduction

In the past few months, we’ve heard consistent feedback from users and partners: while our goal of providing a scalable, high-performance alternative to pgvector is well-received, index build time and memory usage remain major concerns at billion-scale.

Now VectorChord can index 100 million 768-dimensional vectors in 20 minutes on a 16 vCPU machine with just 12 GB of memory. By contrast, indexing the same data with pgvector requires around 200 GB of memory and about 40 hours on a 16-core instance. And pgvector with insufficient memory often suffer from page swapping, making builds even slower.

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.

Optimize RAG with Contextual Retrieval in PostgreSQL

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

In the standard approach to Retrieval Augmented Generation (RAG), a common practice is to break down large documents into smaller, more manageable chunks. This is primarily done to improve the efficiency of the retrieval process, leveraging the sentence embedding and keyword bm25 scoring, allowing systems to quickly find and pull relevant pieces of information. While effective in many scenarios, this method can introduce a significant challenge: the potential for individual chunks to lose their surrounding context.

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

Introducing Vechord: Turn PostgreSQL into your search engine in a Pythonic way.

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

Today, we’re thrilled to announce the release of Vechord, a new Python library designed to dramatically simplify building robust search infrastructure directly on top of the PostgreSQL database.

In the rapidly evolving world of AI and large language models (LLMs), Retrieval-Augmented Generation (RAG) and semantic search have become crucial components. However, setting up the necessary vector search infrastructure often involves learning new database technologies, managing complex integrations, or wrestling with intricate frameworks. This adds friction and slows down development, especially for teams already comfortable with PostgreSQL.

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

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

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!

3 Billion Vectors in PostgreSQL to Protect the Earth

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

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.

PostgreSQL Full-Text Search: Fast When Done Right (Debunking the Slow Myth)

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

You might have come across discussions or blog posts suggesting that PostgreSQL’s built-in full-text search (FTS) struggles with performance compared to dedicated search engines or specialized extensions. A notable recent example comes from Neon’s blog post, “Performance Benchmark: pg_search on Neon” (link).

In their benchmark, Neon compared query performance on their database platform with their pg_search extension (based on Rust’s Tantivy library via pgrx) against the Postgres built-in fulltext search setting with tsvector and GIN index. They commendably stated they optimized this standard setup by adding GIN indexes where appropriate (benchmark code available here).

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

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.

Do we really need a specialized vector database? (2023)

Tue, 18 Feb 2025 00:00:00 +0000

Notice: This article, originally published in 2023, discusses the relevance and necessity of specialized vector databases, particularly in relation to Postgres and its capabilities. For further insights and discussions on this topic, please refer to the following link: Do we really need a specialized vector database? | Hacker News.

With the popularity of LLM (Large Language Model), vector databases have also become a hot topic. With just a few lines of simple Python code, a vector database can act as a cheap but highly effective “external brain” for your LLM. But do we really need a specialized vector database?

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.

Supercharge vector search with ColBERT rerank in PostgreSQL

Thu, 23 Jan 2025 00:00:00 +0000

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.

Why HNSW is Not the Answer

Wed, 18 Dec 2024 00:00:00 +0000

HNSW (Hierarchical Navigable Small World) has become the go-to algorithm for many vector databases. Its multi-layered graph structure and ability to efficiently navigate vector embeddings make it particularly appealing. However, despite its apparent advantages, HNSW may not be the optimal solution for large-scale and dynamic vector similarity search. In this blog post, we challenge the dominance of HNSW and explore why disk-based alternatives, such as IVF (Inverted File Index), might be more practical for massive datasets.

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.

Introducing PGVecto.rs Cloud - Scalable Vector Search in PostgreSQL, Now in the Cloud

Fri, 02 Aug 2024 00:00:00 +0000

In an exciting development, we are thrilled to announce the launch of PGVecto.rs Cloud - bringing the power of scalable vector search to your PostgreSQL databases, now available as a fully managed cloud service.

PGVecto.rs is a pioneering Postgres extension that enables high-performance vector search, empowering developers to build advanced similarity-based applications on top of their existing Postgres infrastructure. With PGVecto.rs Cloud, you can now unlock the benefits of this transformative technology without the overhead of managing the extension yourself.

Introducing Terraform Support for PGVecto.rs Cloud

Wed, 24 Jul 2024 00:00:00 +0000

We are thrilled to announce the release of our Terraform provider for PGVecto.rs Cloud. This new provider is designed to simplify the process of managing resources on our cloud service, providing users with an intuitive and streamlined experience for managing their Postgres cluster setup and operation through infrastructure as a code tool — Terraform. For those unfamiliar with Terraform, it is an open-source tool for building, changing, and versioning infrastructure safely and efficiently. It enables users to define their infrastructure as code, allowing them to provision and manage resources programmatically.

Unleash the power of sparse vector

Fri, 05 Jul 2024 00:00:00 +0000

This post explores how to use how BGE-M3 and pgvecto.rs to exploit the potential of hybrid search using both sparse and dense vectors.

Let’s dive in.

An Overview of Sparse and Dense Vector Embedding

Sparse vectors are high-dimensional vectors that contain few non-zero values. They are suitable for traditional information retrieval use cases. For example, a vector with 32,000 dimensions but only 2 non-zero elements is a typical sparse vector.

pg_bestmatch.rs: Elevate Your PostgreSQL Text Queries with BM25

Fri, 14 Jun 2024 00:00:00 +0000

Tip

Update: Check our latest extension VectorChord-BM25 for end2end BM25 ranking in PostgreSQL. Read more at https://vchord.pgsty.com/blog/post/vectorchord-bm25-revolutionize-postgresql-search-with-bm25-ranking-3x-faster-than-elasticsearch/

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

We’re excited to announce the release of pg_bestmatch.rs, a PostgreSQL extension that brings the power of Best Matching 25 Score (BM25) text queries to your database, enhancing your ability to perform efficient and accurate text retrieval. This extension allows users to generate BM25 statistic sparse vectors from text, leveraging the proven performance of BM25 in various benchmark tasks.

My binary vector search is better than your FP32 vectors

Fri, 22 Mar 2024 00:00:00 +0000

Within the field of vector search, an intriguing development has arisen: binary vector search. This approach shows promise in tackling the long-standing issue of memory consumption by achieving a remarkable 30x reduction. However, a critical aspect that sparks debate is its effect on accuracy.

We believe that using binary vector search, along with specific optimization techniques, can maintain similar accuracy. To provide clarity on this subject, we showcase a series of experiments that will demonstrate the effects and implications of this approach.

pgvector vs. pgvecto.rs in 2024: A Comprehensive Comparison for Vector Search in PostgreSQL

Tue, 19 Mar 2024 00:00:00 +0000

pgvector and pgvecto.rs are both vector search extensions designed to enhance the capabilities of PostgreSQL. These extensions revolutionize the way vector search is performed within the database, providing scalable, low-latency, and hybrid-enabled solutions. In this blog post, we will illustrate the differences between pgvector and pgvecto.rs.

TL; DR: Please navigate directly to the final section that contains a table showcasing the main distinctions between the two.

Search

Building LLM Applications in LangChain using pgvecto.rs

Fri, 08 Mar 2024 00:00:00 +0000

LangChain is a framework for developing applications powered by language models. It enables applications that:

Are context-aware: connect a language model to sources of context (prompt instructions, few shot examples, content to ground its response in, etc.)
Reason: rely on a language model to reason (about how to answer based on provided context, what actions to take, etc.)

pgvecto.rs is a vector search extension in Postgres. In this blog post, we’ll show you how to build LLM applications with LangChain and pgvecto.rs.

Building the RAG pipeline with LlamaIndex and pgvecto.rs

Fri, 08 Mar 2024 00:00:00 +0000

LlamaIndex is a simple, flexible data framework for connecting custom data sources to large language models (LLMs).

pgvecto.rs provides a LlamaIndex integration that allows you to retrieve the most similar vectors. In this blog post, we will show you how to build a RAG pipeline with pgvecto.rs and LlamaIndex.

Install dependencies

Some dependencies are required to use the LlamaIndex integration:

pip install llama-index "pgvecto_rs[sdk]"

You could start the Postgres instance with pgvecto.rs extension in a docker container:

Do we really need a specialized vector database?

Fri, 08 Mar 2024 00:00:00 +0000

Why does LLM need vector search?

First, let me briefly introduce why LLM needs to use vector search technology. Vector search is a problem that has been around for a long time. The process of finding the most similar object in a collection given an object is vector search. Text/images, etc. can be converted into a vector representation, and the similarity problem of text/images can be transformed into a vector similarity problem.

pgvecto.rs 0.2: Unifying Relational Queries and Vector Search in PostgreSQL

Tue, 20 Feb 2024 00:00:00 +0000

We are excited to announce the release of pgvecto.rs 0.2, a significant milestone in the journey of bridging the gap between relational queries and vector search in PostgreSQL. This update brings together the power of both worlds, offering enhanced efficiency and enabling complex queries within PostgreSQL.

In the past, developers and data scientists encountered the significant challenge of managing separate systems for relational queries and vector search. This resulted in increased complexity and resource overhead. However, with the release of pgvecto.rs 0.2, we have addressed this issue by integrating the cutting-edge VBASE method from OSDI 2023. This integration has substantially refined the efficiency of vector search within PostgreSQL.

Vchord: Scalable Vector Search for PostgreSQL on Vchord

Cloud Limits

Cloud Pricing

Free Tier

Configuration

Logging

Index configuration

Connecting with psql

Contributing to `pgvecto.rs`

Code of conduct

Subscribe by Adding Credit Card

Development

Set up development environment

Leveraging 3 Billion PostgreSQL Vectors: Earth Genome's Earth Index & VectorChord for Planetary Protection

General FAQ

The vector type or operator class is not found

Half-Precision Vector: `vecf16`

Hybrid search with Postgres Native BM25 and VectorChord

Hybrid Search

Vector Search and Full Text Search

Indexing

Indexing

Indexing & Maintenance

Creating a bm25 Index

Stable Releases (v0.1 – v0.3, bm25vector)

Next-Gen main Branch (tsvector)

LangChain

Install dependencies

License

Software License (pgsty/vchord & pgsty/vchord_bm25)

Software License (pgsty/pg_tokenizer)

Documentation License (vchord.pgsty.com)

Migration

outline: [2,3]

VectorChord Migration Overview

From PGVecto.rs

Prerequisites

Monitoring

Storage Usage

RAM

Overview

How VectorChord-BM25 Solves Both Problems

Overview of the cloud object hierarchy

VectorChord Cloud Account

Projects

Overview

Features

Overview

What is pgvecto.rs

Price Benchmark

Schema

List of data types

List of operators

List of functions

List of casts

List of access methods

List of operator families

List of operator classes

List of views

Sign up for a cloud account

Sign up

SQL Reference

vchord_bm25 Data Types

bm25vector Literal Syntax (v0.1 – v0.3)

vchord_bm25 Operators

vchord_bm25 Functions

vchord_bm25 Access Method & Operator Class

pg_tokenizer Functions (tokenizer_catalog)

Tokenizer Architecture & Usage

Two-Stage Tokenization Pipeline

Creating and Using a Tokenizer

Troubleshooting

Connectivity

1. Cluster is not reachable, you can check the following:

8-Bit Integer Vector: `veci8`

Adaptive retrieval and shortening embeddings

Attribution & Provenance

Upstream Sources

Supercharge vector search with ColBERT rerank in PostgreSQL

Collect Metrics

Creating a `bm25` Index

Stable Releases (`v0.1` – `v0.3`, `bm25vector`)

Next-Gen `main` Branch (`tsvector`)

Software License (`pgsty/vchord` & `pgsty/vchord_bm25`)

Software License (`pgsty/pg_tokenizer`)

Documentation License (`vchord.pgsty.com`)

What is `pgvecto.rs`

`vchord_bm25` Data Types

`bm25vector` Literal Syntax (`v0.1` – `v0.3`)

`vchord_bm25` Operators

`vchord_bm25` Functions

`vchord_bm25` Access Method & Operator Class

`pg_tokenizer` Functions (`tokenizer_catalog`)

Stable Releases (`v0.1.0` – `v0.3.0`): `bm25_catalog.*` GUCs

Examples (`v0.1` – `v0.3`)

Next-Gen `main` Branch: `bm25.*` GUCs & Index Reloptions

Options for table `segment`

Options for table `optimizing`

Why `to_bm25query` Requires the Index Name

Why `vchord_bm25` Achieves High QPS

Retrieval Accuracy Benchmark (`NDCG@10` on BEIR & LoTTE)

Workflow A: `bm25vector` + `pg_tokenizer` (`v0.1` – `v0.3`)

1. Enable Extensions and Configure `search_path`