Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog From Open-Source Extension to Production-Grade Engine: A New Paradigm for Vector Capabilities in PolarDB for PostgreSQL

From Open-Source Extension to Production-Grade Engine: A New Paradigm for Vector Capabilities in PolarDB for PostgreSQL

This article introduces how PolarDB for PostgreSQL transforms pgvector into a production-grade vector engine supporting billion-scale, millisecond retrieval.

By Liu Chengshan

Introduction

Drawing on our team's engineering practice and independent analysis, this article works through five main threads — quantization → performance enhancements → ecosystem enhancements → massive-scale scenarios → foundation capabilities — to systematically unpack how PolarDB for PostgreSQL, the cloud-native database under ApsaraDB family, upgrades pgvector from an open-source extension into an integrated vector database engine that supports billions of vectors with millisecond response times.

1. Background: The Three-Way Trade-off Facing Vector Databases

Since 2023, vector databases have evolved through three stages: type support (introducing vector types and distance operators), retrieval acceleration (millisecond-level response via ANN indexes such as IVF and HNSW), and production readiness (the engineering capabilities needed to run billions of vectors at thousands of QPS). Systemic gaps in engineering capability came to a head in that final stage.

The core challenge of this stage can be framed as the vector database "impossible triangle":

1
The vector database impossible triangle

The difficulty of this impossible triangle is that any approach solving only one vertex typically needs the other two vertices as support.

Based on this observation, our approach is to systematically close pgvector's engineering gaps in large-scale production scenarios on top of the integrated database architecture of PolarDB for PostgreSQL, so that vector retrieval integrates deeply with the database kernel, storage, compute, and operations systems. Concretely, this comes down to the five actions shown below:

2

The sections below cover each in turn.

2. Quantization: The Key to Serving Billions of Vectors on a Single Node

Overview

Quantization applies lossy compression to vectors under controllable precision, cutting the storage and compute cost of a single vector to between 1/4 and 1/64 of the original.

What We Built

pgvector on PolarDB for PostgreSQL supports both IVF + Quantization and HNSW + Quantization index frameworks, and covers the three mainstream quantization schemes in the industry: PQ, SQ, and RaBitQ.

▲ The core differences among the three schemes:

• Product Quantization (PQ): splits a high-dimensional vector into M sub-segments and trains a codebook independently for each. It offers a high compression ratio, with recall accuracy dependent on codebook training quality.

• Scalar Quantization (SQ): applies linear quantization to each dimension independently (float32 → int8/int4). It is simple to implement with low training cost, offering the best cost-effectiveness.

• Random Bit Quantization (RaBitQ): based on random orthogonal transformation plus 1-bit quantization, with a provable precision lower bound in theory.

Choosing a quantization scheme involves many factors — dataset size, feature concentration, feature dimensionality, whether sampling is required, and more — so it is hard to guarantee that any single scheme, or even a few, will cover every scenario. We therefore offer the following guidance.

Selection Guidance

3

💡 Key capability: the core value of quantization lies in matching the optimal scheme to each business scenario, rather than chasing a single best answer.

3. Performance Enhancements: Rounding Out pgvector's Engineering Capabilities

Beyond capacity, this section focuses on write throughput, long-term stability, and performance consistency.

1. Bulk I/O + prefetch acceleration: improving batch I/O throughput for builds and queries

pgvector's native index build follows the standard PostgreSQL buffer manager path: every page written goes through the shared buffer, acquires a lock, generates WAL, and is then flushed asynchronously. Once vectors reach the billions and index size grows to hundreds of GB, buffer I/O becomes the key bottleneck for overall performance. To address this, we introduced batch read/write for index builds and a prefetch window for queries, targeting vector index and query scenarios to reduce small-I/O contention.

In testing, this approach significantly accelerated builds and queries at the billion-vector scale, delivering a 1.5×–2× improvement.

2. FSM overhaul: doubling INSERT efficiency

In real production, we identified a hidden bottleneck in large-volume INSERT scenarios:

🔬 The original pain point: many vector engines lack independent Free Space Map (FSM) management. When free pages appear in an index, a new INSERT can only scan data pages sequentially to locate available space, and I/O contention rises sharply with data volume.

We introduced an efficient FSM management mechanism that resolves I/O blocking in insert scenarios. In testing under sustained INSERT at the billion-row scale, I/O contention dropped by 90% and p99 write latency became noticeably steadier.

3. Next-generation VACUUM: keeping index pages sustainable

Vector data is characterized by large individual vectors, so reusing space from old data efficiently is key to the long-term stability of vector workloads.

We are adapting more general-purpose vector data cleanup logic — through the index_bulk_delete/index_vacuum_cleanup framework — which, combined with the FSM overhaul from the previous section, closes the loop so that under sustained high-write/high-delete workloads, the index bloat rate shifts from "linear growth" to "steady and controllable."

Beyond this, we provide a range of performance-acceleration techniques across I/O, parallelism, and caching, allowing strategies to be tuned flexibly for the bottlenecks of different scenarios.

4. Ecosystem Enhancements: In-House polar_vectorboost Connects the Vector Retrieval Engineering Pipeline

Many teams adopting vector retrieval for the first time have to hand-write large amounts of fusion query logic. This is not only tedious to implement but also commonly runs into engineering challenges such as a high barrier to invocation, inconsistent scales, missing fusion ranking, and poor recall stability.

The Solution

Our in-house vector ecosystem enhancement extension, polar_vectorboost, compresses "high-frequency SQL" into a single function call. Its core capabilities fall into three areas:

🟢 Automated foundational operations

-- One SQL statement completes: add the  embedding column + automatic tokenization + backfill data + recommend indexes + register meta information SELECT step, status FROM polar_vectorboost.bootstrap(
    'faq', 'content',
    index_name => 'faq_idx',
    id_column  => 'id');

Core functions include:

  • bootstrap: connects to polar_ai to automatically add an embedding vector(N) column and a v tsvector column to a text table;
  • register_index / list_indexes / drop_index: a metadata registry that simplifies the workflow;
  • recommend_vector_index: recommends an index choice automatically based on data volume and dimensionality.

🟡 Hybrid recall + fusion ranking

SELECT * FROM polar_vectorboost.hybrid_search(
    'faq_idx',                              -- The registry's index_name
    query_text    => 'Cloud-native Database',
    top_k         => 10,
    fusion        => 'weighted',
    vector_weight => 0.7);                  -- Vector-biased

It supports two fusion algorithms — Reciprocal Rank Fusion (RRF), the scale-insensitive industry standard, and Weighted (min-max normalized) — and automatically joins tsquery terms with OR to avoid the recall collapse caused by plainto_tsquery's default AND joining.

🔵 Tuning and diagnostics

Function Problem it solves
recommend_fts_config Samples text, automatically determines the CJK / Latin ratio, and recommends a jiebacfg / english / simple tokenizer
check_setup Checks whether columns exist, their types, dimension consistency, and whether an index is built; returns OK / WARN / ERROR per row
check_embeddings Counts NULL vectors, zero-norm vectors, and dimension-mismatched samples, giving up to 5 example ctids
explain_hybrid Returns the actual EXPLAIN plan executed by hybrid_search, for performance profiling and troubleshooting

💡 Core philosophy: polar_vectorboost aims to standardize the general-purpose engineering capabilities of a RAG system — from index building and hybrid recall to performance diagnostics — minimizing repeated reinvention on the business side so developers can focus on data and applications themselves.

5. Massive-Scale Scenarios: Adapting pgvector for Distributed Deployment

The core challenge of vector workloads lies in future data growth: expansion along any dimension — multimodal, multi-version, or multi-tenant — can exceed single-node capacity. PolarDB for PostgreSQL has therefore completed the distributed adaptation of pgvector, with the following core mechanisms:

4

The core approach can be summed up in three points:

  1. Data is partitioned by hash or range across multiple compute nodes, and each node maintains the HNSW / IVF index for its own shard locally.
  2. Queries use a scatter-gather mode: the coordinator node broadcasts the query vector to all shards, each shard performs local top-k recall, and the coordinator node does the global merge.
  3. Writes and data operations are fully distributed, no longer constrained by a single node's CPU, memory, or I/O.

From the user's perspective, distribution brings not just "bigger" but three qualitative changes:

Dimension Single-node mode Distributed mode
Capacity Single-node storage ceiling (~TB range) Horizontal scaling, up to PB scale
Write throughput Single-node CPU ceiling Linear scaling, approximately ×N with N nodes
Failure recovery The entire database is affected Shard-level disaster recovery, globally controllable

🎯 Key takeaway: in vector scenarios, distributed capability is not merely a matter of capacity expansion; it also determines whether the system remains sustainable under long-term growth.

6. Foundation Capabilities: Engineering Support Built on PolarDB for PostgreSQL

Vector capabilities can run stably in production fundamentally because they sink down onto the native foundation capabilities that PolarDB for PostgreSQL has accumulated over years.

▲ The foundation capability stack:

• High-performance architecture: deep kernel optimization combined with physical replication, an RDMA high-speed network, and distributed shared storage.

• Fast elasticity: second-level scaling up and down (a one-writer-multiple-reader architecture with a maximum capacity in the TB range), scalable horizontally to multiple compute nodes.

• Mixed workloads: a cross-machine parallel query engine that executes SQL cooperatively across nodes to accelerate analytical queries.

• Hot-cold storage tiering: for billion-scale vector stores, hot shards reside in the high-speed tier while cold shards sink to object storage, balancing cost and performance.

• Seamless ecosystem integration

  • polar_ai: natively provides AI functions such as ai_text_embedding(text), so vectorization never leaves the database;
  • pg_jieba / GIN full-text search: hybrid retrieval with vector recall within the same transaction, with no cross-system ETL;
  • Mature extensions such as pg_cron / pglogical / pg_partman can be reused directly, tapping into the database operations ecosystem.

For more capabilities, see the official documentation:
https://www.alibabacloud.com/product/polardb-for-postgresql

🔑 Key takeaway: vector capability focuses primarily on the retrieval layer, while overall availability in production depends to a large extent on the support of the underlying database foundation.

7. Summary

PolarDB for PostgreSQL's enhancements to vector capabilities can be summarized as a systematic upgrade across the following five dimensions. Each addresses a key engineering bottleneck constraining pgvector's path to production readiness, rather than a single performance metric.

5

The long-term value of a vector database does not hinge on the peak performance of any one specialized capability, but on how deeply it integrates with the core database and on its ability to provide sustainable support in real business scenarios. By evolving continuously along the five threads above, pgvector on PolarDB for PostgreSQL has grown from an open-source extension into an integrated vector database engine that supports billions of vectors with millisecond response times.

PostgreSQL Database POLARDB Cloud-Native Database Distributed Database Vector Retrieval PolarDB for PostgreSQL Vector database RAG Hybrid Search pgvector
0 1 0
Share on

Read previous post:

Alibaba Cloud ApsaraDB Data Agent Enterprise Edition Helps You Master Your Data with Ease

Read next post:

PolarDB-X Storage Engine Internals | Native Multi-Version Unique Key Index — Panda Index

ApsaraDB

645 posts | 186 followers

You may also like

Comments

ApsaraDB

645 posts | 186 followers

Related Products

More Posts by ApsaraDB

See All