Data & documents

Timescale releases pg_vectorsearch for high-performance PostgreSQL vector indexing

Timescale has released an alpha extension called pg_vectorsearch that introduces the PRISM index for faster approximate nearest neighbor search in PostgreSQL.

Illustration of vector data structures inside a glass cube on a desk
Illustration generated for this article

Timescale has released pg_vectorsearch, a new PostgreSQL extension designed to accelerate approximate nearest neighbor search for vector data. Published on October 14, 2026, this alpha-stage tool introduces the PRISM index, which aims to outperform existing solutions like HNSW and IVFFlat in both speed and memory efficiency. The release targets developers building retrieval-augmented generation systems who need scalable vector infrastructure within their existing relational databases.

What happened

The core of this release is the PRISM index, which stands for Partitioned Routing Index for Similarity Matching. It is implemented in C to ensure tight integration with PostgreSQL internals. According to the announcement, PRISM is significantly faster than pgvector’s IVFFlat and HNSW indexes for both querying and index building. In benchmarks involving a dataset of 100 million vectors, PRISM achieved equivalent recall to graph-based HNSW while using only a quarter of the memory and delivering faster query times.

This extension supports dynamic updates, allowing for inserts, updates, and deletes without requiring a full index rebuild. However, the maintainers explicitly state that the software is currently in alpha status and is meant for testing rather than production use. Upgrading between prereleases may not be possible, so users are advised to plan for dropping and recreating the extension and its indexes as the project evolves. Known issues are tracked in the changelog.

How it works

PRISM uses a hierarchical centroid tree to partition vectors into clusters, relying on the PostgreSQL buffer cache to keep this routing structure in memory. This approach allows the system to quickly identify relevant clusters without scanning the entire dataset. Once the nearest clusters are identified, the system scans posting lists to generate candidate vectors. These lists are optimized for SIMD distance computation, utilizing AVX2, AVX512, and NEON instructions to accelerate calculations on compatible hardware.

A key technical feature is the use of RaBitQ quantization. This method encodes vectors with theoretical error bounds, enabling a two-stage search process. The first stage estimates distances and uses error bounds to rule out vectors that cannot possibly be nearest neighbors. This filtering step significantly reduces the number of candidates that require reranking against full-precision vectors stored in the table heap. The final step returns the k nearest neighbors after this efficient filtering and reranking process.

Key details

  • Index type: PRISM (Partitioned Routing Index for Similarity Matching), which is IVF-style with hierarchical routing.
  • Quantization: Uses RaBitQ quantization with theoretical error bounds for efficient two-stage search filtering.
  • Hardware acceleration: Distance computations are optimized for SIMD instructions including AVX2, AVX512, and NEON.
  • Compatibility: Can index existing pgvector vector and halfvec columns directly, or use native vec32 and vec16 types.
  • Maintenance: Supports dynamic inserts, updates, and deletes, with posting-list splits managed via the prism_rebalance procedure.
  • Status: Alpha release intended for testing; upgrading between prereleases may require dropping and recreating indexes.

Why it matters

For engineers building AI applications, vector search performance often becomes a bottleneck as datasets grow. Traditional graph-based indexes like HNSW can consume significant memory, increasing infrastructure costs. By demonstrating that PRISM can handle 100 million vectors with a fraction of the memory required by HNSW, this extension offers a path to more cost-effective scaling. It allows teams to keep their vector data alongside their transactional data in PostgreSQL, simplifying architecture and reducing the need for separate vector database services.

The compatibility with existing pgvector tables is particularly important for migration. Developers do not need to rewrite their schemas or application logic to test the new index. They can install pg_vectorsearch alongside pgvector and build a PRISM index on existing columns. This lowers the barrier to entry for evaluating whether the performance gains justify the operational complexity of adopting a new indexing method, even in its early alpha stage.

What you can do

  • Install PostgreSQL 18 or later along with a GNU C11 compiler such as GCC 11+ or Clang 14+ to prepare your environment.
  • Build the extension from source using the Meson build system, ensuring you have the necessary PostgreSQL development headers.
  • Test the extension on non-production datasets by creating a PRISM index on existing vector or halfvec columns.
  • Experiment with the prism.nprobe parameter to tune the trade-off between query speed and recall accuracy for your specific workload.
  • Monitor the changelog for known issues and be prepared to drop and recreate indexes when testing new prerelease versions.
  • Evaluate the prism_rebalance procedure for maintaining index performance during dynamic insert and update operations.

Tools from the Bytechap store

Keep reading

All stories