pg_vectorsearch vs pgvector: PRISM vs HNSW build times, filters and which index takes the vector slot in Postgres

No managed Postgres service offers pg_vectorsearch yet

As of 17 October 2026, pg_vectorsearch is not on the extension lists of AWS RDS and Aurora, Google Cloud SQL and AlloyDB, Azure Database for PostgreSQL, Supabase, Neon or Tiger Data's own Tiger Cloud. pgvector is on all of them. Using pg_vectorsearch today means running Postgres 18 yourself and building the extension from source.

A Tiger Data employee wrote on Hacker News that "you can always move to tiger cloud if you want it managed"; Tiger Cloud's extension page lists pgvectorscale but not pg_vectorsearch. Each big provider also ships its own answer to the memory problem: Azure has pg_diskann, AlloyDB has ScaNN, and AWS points to Aurora Optimized Reads, which caches on local NVMe.

What switching from pgvector to pg_vectorsearch costs

Switching from pgvector to pg_vectorsearch is an index swap, not a data migration, once you are on Postgres 18. PRISM reads pgvector's vector and halfvec columns as they are, and queries using pgvector's operators work unchanged. The costs are the Postgres upgrade, expression indexes, the tuning settings and the extra maintenance under churn.

From the pg_vectorsearch README, with the plan output it shows left out:

-- Install pg_vectorsearch next to pgvector and build the index on the
-- existing column. The column is not rewritten or copied.
CREATE EXTENSION pg_vectorsearch;

CREATE INDEX documents_embedding_prism
    ON documents USING prism (embedding vec32_l2_ops);

-- Your queries keep working as before. PRISM is normally faster, so
-- the planner should prefer it over the HNSW index while both exist.
-- Verify with an EXPLAIN:
EXPLAIN (COSTS OFF)
SELECT id, body
FROM documents
ORDER BY embedding <-> (SELECT embedding FROM documents WHERE id = 42)
LIMIT 10;

-- Once you are happy with it, drop the HNSW index.
DROP INDEX documents_embedding_hnsw;

The operator classes map one to one: vector_<metric>_ops becomes vec32_<metric>_ops and halfvec_<metric>_ops becomes vec16_<metric>_ops. The query knob changes from hnsw.ef_search to prism.nprobe, where 0 means automatic, aimed at about 95% recall.

What else changes:

• Expression indexes. A common pgvector setup, and the one Tiger Data benchmarked, indexes (embedding::halfvec(N)). PRISM refuses expression indexes, so you index the full column or convert it to halfvec, and queries that cast change with it.
• Load first, index after. PRISM sizes its partitions from the row count at CREATE INDEX and is not recommended on an empty table filled afterwards, which does not suit schema migrations that create indexes before data arrives.
• Churn. Rows inserted after the build get no boundary copy, deleted space comes back only on REINDEX, and Freedman wrote that "for workloads with substantial churn, REINDEX is still needed".
• Upgrades. There is no upgrade path from the release candidates; Tiger Data says upgrades between final releases will ship an upgrade script from 0.1.0 on.

Rollback is cheap: both extensions run in one database, so you can keep the HNSW index until EXPLAIN shows PRISM in use and the recall checks pass.

BM25 next to vectors in the same database

Keyword search with BM25 ranking and vector search can share one Postgres database, and reciprocal rank fusion merges the two result lists in plain SQL. Two extensions provide BM25: ParadeDB's pg_search and Tiger Data's pg_textsearch. Either sits next to a pgvector or PRISM index.

The choice is mostly about where you run Postgres. pg_textsearch uses the PostgreSQL licence and is on Cloud SQL, AlloyDB and Tiger Cloud. pg_search is AGPL-3.0 in its community edition, which "supports single-node deployments", and is not on the managed lists checked; ParadeDB documents running it as a logical replica of a managed primary. pg_search also indexes vectors itself, in beta.

On speed, Alex Georgiev measured a ten-term search falling from about 129 ms to 29 ms between pg_search 0.25.11 and 0.26.0, while a single-term search got about five times slower. The test ran in Docker containers on a host the article does not describe, and the published script makes 500,000 rows where the article says three million.

When a separate vector store is the right slot

A Postgres extension is the wrong slot when the index outgrows one machine, when writes are heavy and constant, or when every query is scoped to one of many tenants. pgvector's README sends horizontal scale to replicas or sharding tools such as Citus, and Tiger Data's launch post lists parallel query, multi-tenant indexes and a billion-vector test as later work.

Below that, keeping vectors in Postgres keeps one backup, one permission model and one transaction around them. On Stackness, 6 public profiles list PostgreSQL as of 17 October 2026 and 3 of those also list Supabase; none list ParadeDB, pgvector or a separate vector store yet (data sources). The sample is small. The rest of the DevOps and infrastructure tools developers list is one click away.

Pick pgvector if, pick pg_vectorsearch if

Pick pgvector if:

• you run a managed Postgres service, or any version before 18
• your queries filter by tenant, type or date
• your HNSW graph fits in RAM and builds in an acceptable window
• you need L1, Hamming or Jaccard distance, sparse vectors, or more than 1,968 dimensions
• the index has to be in production this quarter

Pick pg_vectorsearch, on a test copy first, if:

• you self-host Postgres 18
• your HNSW graph no longer fits in RAM and queries have slowed to hundreds of milliseconds
• HNSW rebuilds take hours and block deploys
• you need 99% recall at 100 million vectors, which HNSW did not reach in Tiger Data's runs
• your writes come in batches you can follow with a REINDEX