Junyu Chen on Vchord

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

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

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

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

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.

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: 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.

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).

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.

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.

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.

Unleash the power of sparse vector

Fri, 05 Jul 2024 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.

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.