pgvectorsearch Alpha Targets 100M on pgvector Columns
Tiger Data’s PRISM index preserves existing embeddings and queries, but PostgreSQL 18 requirements and first-party benchmark claims make this a sandbox experiment.
AI SummaryGenerated from this article
Tiger Data's pg_vectorsearch extension introduces PRISM, an alpha-stage vector index for PostgreSQL 18 targeting 100-million-vector datasets. PRISM uses hierarchical partitioning and RaBitQ quantization instead of graph-based approaches, indexing existing pgvector columns without data migration or query rewrites. Tiger Data reports faster builds and lower memory than pgvector's HNSW on first-party benchmarks, though independent validation is needed. The extension requires PostgreSQL 18, carries alpha stability warnings, and demands careful evaluation on production workloads before deployment. Teams should test on isolated copies, establish ground-truth recall metrics, and account for maintenance limitations before considering production use.
PostgreSQL teams can test Tiger Data’s new PRISM vector index without converting their existing pgvector columns or rewriting their nearest-neighbor queries. The company’s pg_vectorsearch extension indexes existing vector and halfvec columns directly, making it relatively easy to compare another approximate nearest-neighbor search approach.
That compatibility comes with a qualification: pg_vectorsearch is alpha software, explicitly intended for testing rather than production. Prerelease upgrades may require dropping and recreating the extension and its indexes.
For infrastructure teams supporting retrieval-augmented generation and other AI products, PRISM offers a testable alternative targeting datasets of 100 million vectors or more. Tiger Data reports substantial improvements over pgvector’s HNSW and IVFFlat indexes, but those results remain first-party claims. Teams will need to see whether PRISM reproduces a useful advantage on their own data, hardware, and retrieval workloads.
Existing Columns Lower the Cost of an Experiment
PRISM is a PostgreSQL-native index access method. Teams already storing embeddings with pgvector can install pg_vectorsearch alongside it and build an additional index on the same column.
According to the repository, this operation does not rewrite or copy the embeddings, and the existing table and query syntax remain unchanged. Building the index still creates index data and consumes resources. Compatibility saves teams an embedding migration; it does not remove the cost of indexing.
The extension’s native vec32 and vec16 types are binary-compatible with pgvector’s vector and halfvec, respectively. Their different names allow both extensions to coexist, including in the same schema.
Distance operators also stay familiar:
L2 distance uses <->.
Inner product uses <#>.
Cosine distance uses <=>.
The index operator class must match the column type and distance metric. For example, an existing vector_l2_ops index maps to PRISM’s vec32_l2_ops; halfvec columns use the corresponding vec16_* classes.
On an isolated copy of an existing database, an L2 example adapted from the repository looks like this:
Work with Zeniteq
Let’s work together
We’re open to thoughtful collaborations with teams building in AI. Explore the ways we can work together.
CREATE EXTENSION pg_vectorsearch;
CREATE INDEX documents_embedding_prism
ON documents USING prism (embedding vec32_l2_ops);
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, body
FROM documents
ORDER BY embedding <-> (
SELECT embedding
FROM documents
WHERE id = 42
)
LIMIT 10;
This assumes the copied documents table already has a pgvector vector column named embedding. A cosine workload needs the cosine operator and matching operator class instead. Since EXPLAIN ANALYZE executes the query, this is a test-environment example, not a production rollout instruction.
The current build needs PostgreSQL 18 or newer, development headers, a GNU C11 compiler such as GCC 11+ or Clang 14+, and Meson. Teams running older PostgreSQL versions face an environment upgrade even though their embedding schema is compatible. The project uses the permissive PostgreSQL License.
PRISM Uses Partitioning and Quantization Instead of a Graph
PRISM stands for Partitioned Routing Index for Similarity Matching. The repository describes it as conceptually similar to IVFFlat, with additional hierarchical routing, quantization, and partitioning techniques.
A hierarchical centroid tree groups vectors into clusters. A query traverses that tree, scans candidate posting lists, filters candidates using RaBitQ quantization, and reranks the survivors against the original vectors stored in the table.
Quantization provides a compact representation for screening candidates before fetching their original embeddings. The repository says RaBitQ’s error bounds help eliminate candidates that cannot beat nearer candidates, reducing reranking work.
The overall search is still approximate. Routing selects which clusters to inspect, so the search can miss neighbors outside those clusters. Teams need to measure retrieval recall independently; quantization error bounds do not guarantee complete results.
The implementation includes SIMD-optimized distance computation for AVX2, AVX-512, and NEON. Its architecture aims to make candidate scanning efficient while using PostgreSQL’s buffer cache for the routing tree and posting lists.
Performance therefore depends on more than vector count. Hardware, cache state, candidate selection, and the cost of fetching original vectors all belong in the evaluation. Fast candidate screening may still leave another bottleneck on a workload with large rows or substantial filtering.
The 100M Benchmark Is a Vendor Result, Not a Verdict
In its published benchmark summary, Tiger Data describes a test involving 100 million Cohere embeddings. The company says pgvector’s HNSW build could not finish on a machine with 128 GiB of RAM, so it moved that build to a 512 GiB machine.
Its reported comparison is:
Measure
PRISM
pgvector HNSW
Machine RAM
128 GiB
512 GiB
Index build time
1 hour 40 minutes
42 hours
Query latency at 95% recall
6 ms
8 ms
These are Tiger Data’s figures, not independently verified results. The repository also claims faster querying and index building than pgvector’s IVFFlat and HNSW.
The comparison uses machines with different RAM capacities. It does not establish that PRISM always consumes exactly one quarter of HNSW’s memory, though it suggests a potentially useful difference in hardware requirements under the company’s test conditions.
Build time could matter as much as query latency. Infrastructure teams must rebuild indexes, recover environments, and accommodate growing datasets. A shorter build can reduce operational disruption even when both indexes meet the application’s query-latency target.
The headline numbers do not establish performance for every embedding model, distance metric, filter pattern, or concurrency level. Before using them to support a purchasing or architecture decision, teams should reproduce the comparison with recorded extension versions, build parameters, hardware, and query settings.
A Fair Test Needs More Than Two Indexes on One Table
Coexistence makes compatibility testing convenient, but it does not automatically produce a valid performance comparison.
The repository’s example leaves HNSW and PRISM indexes on the same table and checks which one PostgreSQL chooses. This demonstrates how unchanged queries can use PRISM without ensuring that every subsequent query tests the intended index.
A practical evaluation should separate compatibility checks from controlled benchmarking.
Start with disposable, representative copies. Keep production untouched and pin the pg_vectorsearch commit or prerelease being tested. Match PostgreSQL versions, data, configuration, and hardware when measuring relative performance. Load representative data before building the indexes.
Check coexistence, then isolate each candidate. First verify that the new index builds on the existing column and that application queries still work. For measurements, use equivalent test copies with only the intended ANN index available, and inspect execution plans. Two indexes sharing one instance can complicate cache and resource comparisons.
Establish exact-search ground truth. For a fixed query set and unchanged data snapshot, compute exact nearest neighbors without an ANN index, verifying the plan. Compare each approximate result against that reference. Recall measures how many expected neighbors the approximate search returns.
Tune to comparable recall. PRISM exposes prism.nprobe, which the repository identifies as the main tuning control: increasing it favors recall, while decreasing it favors speed. Compare latency at matching measured recall, not merely at each index’s default settings. Record the corresponding pgvector settings.
Measure application conditions. Record build duration, index size, resource use, throughput, and latency distributions under relevant concurrency. Test cold and warm cache conditions separately. Include the actual filters, result counts, and write patterns used by the application.
For RAG teams, a nearest-neighbor benchmark without tenant restrictions, permissions, or document metadata filters may not represent the retrieval query that reaches production.
Start with a smaller representative dataset to validate the procedure. Its results should not be assumed to predict 100-million-vector behavior: if that scale motivates the evaluation, the eventual test must exercise it and its associated storage and memory pressure.
Alpha Maintenance Limits Belong in the Decision
The repository’s alpha warning is explicit: this is testing software, not production-ready software, and upgrades between prereleases may not work. Teams should budget for recreating the extension and indexes instead of assuming an in-place upgrade path.
PRISM supports inserts, updates, and deletes, though long-running maintenance behavior still needs evaluation. The repository says inserts append to posting lists, which grow without automatically splitting. Its prism_rebalance procedure can split oversized lists in place.
Tiger Data’s benchmark summary also identifies current limitations: manual rebalancing under heavy churn, no space reuse on deletes yet, and filtered streaming search still ahead. Tests should include sustained ingestion, replacement of embeddings, and deletions alongside a static corpus.
The baseline deserves attention here, too. The pgvector changelog records iterative index scans as a feature introduced in version 0.8.0. An evaluation should preserve capabilities the application already depends on, beyond comparing an unfiltered latency number.
The strongest reason to try pg_vectorsearch now is that its compatibility makes a meaningful experiment easier. An alpha index is still unsafe to deploy. A favorable result should justify broader validation covering filtering, churn, rebuilds, and upgrade behavior before it justifies replacing a production index.
