pg_search vs pg_textsearch: BM25 Hybrid Search in Postgres

Pick by topology, cloud and license first, features second. Both extensions give you real BM25 with IDF and length normalisation, and the relevance gap between them on our run was 0.004 nDCG@10, well inside what tokenizer differences explain.

Our default for the reader this post is written for, a platform team at a regulated company running Postgres with a failover standby, is pg_textsearch, with the phrase workaround below until its next release ships Boolean and phrase index scans. Switch to pg_search the moment exact-phrase or fuzzy matching is a hard requirement, and budget for Enterprise if that search has to survive a failover.

pg_search comes from ParadeDB and embeds a Rust search library inside Postgres; the repository has roughly 9,300 stars. pg_textsearch comes from Tiger Data (formerly Timescale) and is written as a native access method that reuses Postgres text search configurations. The table is the whole comparison in one place; the sections after it show the parts that surprised us.

The table leaves performance out on purpose. The Tiger Data release notes claim pg_textsearch outperforms ParadeDB on filtered top-K and, in an earlier release, 3.5 times the query throughput of "the leading Postgres-based BM25 extension" on a 133M-document corpus; those are the vendor's own benchmarks and we found no independent reproduction. The one head-to-head table in those release notes is a write benchmark: at 8 concurrent clients inserting MSMARCO passages, pg_textsearch v1.1.0 did 11,593 TPS and ParadeDB did 12,620 TPS, with no ParadeDB version stated. Treat both as vendor-reported.

Both extensions must be preloaded, which means a restart and a change window. These are the documented installs at the stable tags:

-- postgresql.conf, then restart
shared_preload_libraries = 'pg_search'

-- per database; CASCADE also creates the required vector extension
CREATE EXTENSION pg_search CASCADE;

-- postgresql.conf, then restart
shared_preload_libraries = 'pg_textsearch'

-- per database
CREATE EXTENSION pg_textsearch;

Without CASCADE, pg_search 0.25.11 fails with required extension "vector" is not installed. If this database already serves RAG, pgvector is there; if not, it has to go into the air-gapped package mirror too. pg_search publishes prebuilt packages for Debian, Ubuntu and RHEL on PostgreSQL 15 to 18; pg_textsearch publishes .deb zips and tarballs for PostgreSQL 17 and 18 on amd64 and arm64, and ours installed with dpkg -i on the stock postgres:18 image with no build step.

The indexes we benchmarked, on a docs table with a bigint primary key and a content text column:

CREATE INDEX docs_stem_bm25 ON docs_stem
USING paradedb (id, (content::pdb.simple('stemmer=english', 'stopwords_language=english')))
WITH (key_field='id');

CREATE INDEX docs_bm25 ON docs USING bm25(content) WITH (text_config='english');

Configure the pg_search tokenizer explicitly. Its default tokenizer lowercases but neither stems nor drops stopwords, and on SciFact that cost 0.023 nDCG@10, doubled the index to 10.1 MB and made the median query 4.6 times slower (2.92 ms against 0.64 ms), because every query walked the posting lists of words like "the". The stemmed index turns Running studies of mice into {run,studi,mice}. pg_textsearch inherits whatever Postgres configuration you name, so english gets Postgres's stemmer and stopword list with no extra decision. If you index several languages, pg_textsearch's one-partial-index-per-language pattern maps directly onto one index per language for multilingual RAG; pg_search's one-index-per-table rule pushes you toward separate columns or tables instead, and a second ParadeDB index on the same table fails with a relation may only have one ParadeDB index.

ERROR:  access method "bm25" already exists
CONTEXT:  SQL statement "CREATE ACCESS METHOD bm25 TYPE INDEX HANDLER public.tp_handler"
extension script file "pg_textsearch--1.4.0.sql", near line 32

The setup: BEIR SciFact, 5,183 documents (20 MB of heap) and its 300 test queries, loaded identically into three PostgreSQL 18 containers on a 10-CPU laptop. Each query ran once at LIMIT 100 for quality, then 300 queries were timed at LIMIT 10 after an untimed warm-up pass, from psql over the Unix socket with one client and a warm cache. Neither engine got any query rewriting.

Read it with the caveats attached. This is a small corpus that fits in shared buffers, one client, no concurrent writes; the latencies show relative behaviour, not capacity, and say nothing about 50 million rows. The two BM25 engines used different tokenizers (Postgres english against pg_search's stemmer and stopword filter), and a 0.004 nDCG@10 gap is inside that noise. Call it a tie. The two reruns of the top-10 latency pass were stable within 0.1 ms at p50 for both engines.

Three findings do survive the caveats. First, both BM25 engines roughly double native ts_rank_cd, which has no IDF and was planned as a sequential scan with a top-N sort; the AND variant returned zero rows for 274 of the 300 queries. Second, pg_textsearch's latency grows with k: 1.28 ms at top-10, 10.4 ms at top-100, while pg_search's stemmed index stayed under 1 ms at both. That matters because hybrid search over-fetches 100 or more candidates per branch. Third, check the plan. pg_search's fast path shows Custom Scan (ParadeDB Base Scan) with Exec Method: TopKScanExecState, and only engages with a LIMIT, indexed ORDER BY columns (three at most) and a ParadeDB operator at the same query level; a query with no ParadeDB operator runs as plain Postgres. pg_textsearch's shows Index Scan using docs_bm25 with an Order By on the bm25query.

SELECT id, round(pdb.score(id)::numeric, 4) AS score, content ILIKE '%cancer cells%' AS has_exact_phrase FROM docs_stem WHERE content ||| 'cancer cells' ORDER BY pdb.score(id) DESC, id LIMIT 10;

SELECT id, round((content <@> 'cancer cells')::numeric, 4) AS score, content ILIKE '%cancer cells%' AS has_exact_phrase FROM docs ORDER BY content <@> 'cancer cells' LIMIT 10;

This is where pg_search earns its place. Its ### operator enforces word order and adjacency, and on our stemmed index it agreed exactly with a literal substring search:

SELECT count(*) AS ilike_phrase FROM docs_stem WHERE content ILIKE '%blood pressure%';        -- 81
SELECT count(*) AS ilike_reversed FROM docs_stem WHERE content ILIKE '%pressure blood%';      -- 0
SELECT count(*) AS phrase_hits FROM docs_stem WHERE content ### 'blood pressure';             -- 81
SELECT count(*) AS reversed_phrase_hits FROM docs_stem WHERE content ### 'pressure blood';    -- 0
SELECT count(*) AS conjunction_hits FROM docs_stem WHERE content &&& 'blood pressure';        -- 85

Stemming carries into phrases: ### 'cancer cells' matched 187 documents on the stemmed index, because "cancer cell" counts, against 143 on the unstemmed index and 142 for the literal ILIKE. For clause numbers and defined terms in contracts or regulations, index that column without a stemmer. pg_search also has slop on phrases (::pdb.slop(n)), fuzzy matching up to edit distance 2 (::pdb.fuzzy(n)), phrase prefix, and pdb.parse for user-typed query strings with AND and OR. One trap: quotes inside a ||| string do nothing, and '"blood pressure"' returned the same top 5 as 'pressure blood'.

pg_textsearch 1.4.0 stores term frequencies but not positions. It does not reject phrase syntax; it ignores it. 'blood pressure', '"blood pressure"', 'pressure blood' and 'blood <-> pressure' returned the same five rows with the same scores, and for "cancer cells" 3 of the top 10 did not contain the phrase. ### fails outright with operator does not exist. The README's workaround, over-fetching by BM25 and filtering on the text, worked:

SELECT id, round(score::numeric, 4) AS score FROM (
    SELECT id, content, content <@> 'cancer cells' AS score
    FROM docs
    ORDER BY score
    LIMIT 100
) sub
WHERE content ILIKE '%cancer cells%'
ORDER BY score
LIMIT 10;

It returns only exact-phrase documents, in BM25 order, but a rare phrase can have fewer than 10 hits in the first 100 candidates and you get a short page. That is the same over-fetch problem that filtered vector search runs into at low selectivity, and the same fix: raise the inner limit and measure how often pages come back short. Native @@ with a <-> tsquery also works on the pg_textsearch table, but at 1.4.0 it runs as a sequential scan.

What is coming: Boolean tsquery index scans with &, |, !, <-> phrase and :* prefix were merged on 17 September 2026, and Boolean filtering combined with BM25 ranking was merged on 29 September, labelled "supported, but is not yet optimized". Neither is in a release. Plan against 1.4.0 behaviour until one ships.

Filtering follows the same split. pg_search pushes a WHERE into the index scan when the filter column is in the ParadeDB index, with the literal tokenizer for text equality. pg_textsearch 1.4.0 pre-filters through a separate B-tree or post-filters after the BM25 scan, and its release notes claim filtered top-K got up to 5 times faster in 1.4.0; post-filtering can still return fewer than LIMIT rows, so over-fetch.

Neither extension ships a hybrid operator you can rely on. ParadeDB's README still lists native hybrid search as coming soon, and its in-index vector support added in 0.25.0 is beta, takes only the vector type (no halfvec, which matters if you use it to get past pgvector's 2,000-dimension index limit) and may need a reindex when the storage format changes. So hybrid is still a reciprocal rank fusion query you write, with the vector branch on a normal pgvector HNSW index. The reasons to fuse at all are covered in hybrid dense and sparse retrieval; here is the SQL that ran against pg_textsearch, with embeddings in a side table doc_emb and '<query embedding>' standing in for the vector your application binds:

SET hnsw.ef_search = 100;

WITH text AS (SELECT id, ROW_NUMBER() OVER (ORDER BY score) AS rank FROM (SELECT id, content <@> $q$0-dimensional biomaterials show inductive properties.$q$ AS score FROM docs ORDER BY content <@> $q$0-dimensional biomaterials show inductive properties.$q$ LIMIT 100) t),
vector AS (SELECT id, ROW_NUMBER() OVER (ORDER BY dist) AS rank FROM (SELECT id, embedding <=> '<query embedding>'::vector AS dist FROM doc_emb ORDER BY embedding <=> '<query embedding>'::vector LIMIT 100) v),
fused AS (
    SELECT id, sum(weight) AS score
    FROM (
        SELECT id, 1.0 / (60 + rank) AS weight FROM text
        UNION ALL
        SELECT id, 1.0 / (60 + rank) AS weight FROM vector
    ) u
    GROUP BY id
)
SELECT id, score FROM fused ORDER BY score DESC, id LIMIT 10;

For pg_search, replace only the first CTE; the ranking is ascending in pg_textsearch and descending in pg_search, which is the bug to look for when porting:

WITH text AS (SELECT id, ROW_NUMBER() OVER (ORDER BY pdb.score(id) DESC, id) AS rank FROM docs_stem WHERE content ||| $q$0-dimensional biomaterials show inductive properties.$q$ ORDER BY pdb.score(id) DESC, id LIMIT 100),

Set hnsw.ef_search to at least the branch limit; at the default of 40 the vector branch cannot return 100 candidates. Tuning HNSW for millions of rows covers the rest of that branch.

Both plans used both indexes. The latency gap is the top-100 text branch: pg_textsearch's BM25 index scan took about 12 ms of a 14.9 ms execution. Do not read the quality column as "hybrid loses". Equal-weight RRF scored below BM25 alone here because the dense branch was weak: a 137M-parameter open embedding model at 0.49 nDCG@10, with 354 of the 5,183 documents embedded from truncated text after the local embedding server failed on them. The result proves the SQL works in both engines. Tune the fusion weights against your own labelled queries, and put a reranker after fusion only when your evals show it pays.

CREATE POLICY tenant_a_only ON rls_docs FOR SELECT TO tenant_a_reader USING (tenant = 'a');

SELECT id, content <@> to_bm25query('sanctions', 'rls_docs_bm25') AS score FROM rls_docs ORDER BY content <@> to_bm25query('sanctions', 'rls_docs_bm25') LIMIT 3;

SELECT id, pdb.score(id) AS score FROM rls_docs WHERE content ||| 'sanctions' ORDER BY pdb.score(id) DESC LIMIT 3;

Neither engine returned a hidden row; pg_search applies the policy as a heap filter inside its custom scan, and pg_textsearch's plan shows Rows Removed by Filter: 200. But the score moved by a factor of about 37 in pg_textsearch and 39 in pg_search, because IDF and average length are computed over every indexed row. A tenant-A user who guesses a term (a counterparty name, a case code) can tell whether other tenants' documents contain it. pg_textsearch documents this on its main branch and adds a superuser setting, pg_textsearch.allow_rls, to refuse BM25 indexes on RLS tables; in 1.4.0 SHOW pg_textsearch.allow_rls fails as an unrecognized parameter. We found no mention of RLS in the ParadeDB docs we read.

The fix is structural: never let two clearance levels share an index's statistics. With pg_textsearch, a partial index per tenant or a partition per tenant keeps statistics separate, since both engines compute them per partition. With pg_search, one index per table rules out partial indexes per tenant, so partition or separate tables. That is the silo end of the silo, pool and bridge tenancy models, and it pairs with keeping document ACLs in sync with the source system, because a stale permission is the other way the wrong rows reach a scorer.

The partition side effect: scores from different partitions are not comparable in either engine. pg_textsearch documents partition-local statistics, and ParadeDB has an open issue for cross-partition normalisation. Do not merge top-K across partitions by raw score.

pg_search is AGPL-3.0. ParadeDB Enterprise is commercially licensed, waives the copyleft provision and adds closed-source features. pg_textsearch uses the PostgreSQL license. None of this is legal advice; these are the questions procurement will ask, and it is faster to bring the answers than to wait for them:

For teams that need failover, the license question and the HA question tend to merge: the Enterprise license removes AGPL from the conversation and supplies replicas at the same time. For teams that cannot add a vendor contract, pg_textsearch clears both with no negotiation, and phrase support is the price until its next release.

This week, run one small test: load 1,000 of your own documents into two scratch databases on one server, one per extension, and run 20 real queries from your logs through each, including one exact phrase and one misspelling. Then run EXPLAIN on each and fail over your staging standby. The plans and the failover will settle the choice faster than any benchmark.