Feature comparison matrix — pg_fts vs PostgreSQL BM25 alternatives

Scope: PostgreSQL-embedded BM25 full-text search extensions, plus built-in tsvector/GIN as the baseline everyone already has. Compiled 2026-09-09 against pg_fts v1.6.0.

Competitor rows reflect what we exercised in our own benchmark runs (see bench/BENCHMARK_SUMMARY.md and bench/data_5way_159b/), not vendor claims. Where a capability was not exercised, it is marked untested rather than guessed.

Versions measured: pg_textsearch v1.4.0 (head-to-head 2026-09-30, bench/RESULTS_PGTS_2026-09-30.md; earlier columns f940210); pg_search (ParadeDB) 0.25.6 / paradedb c807ede; VectorChord-bm25 14fc2a3.

Legend: Yes = exercised and working · No = absent · n/t = not tested by us

Not in this matrix: TIN (PlanetScale)

TIN is deliberately absent from every table below, because it cannot be obtained. It is a closed extension available only inside PlanetScale’s managed Postgres: there is no public repository (github.com/planetscale/tin is 404), no source or package referenced in its documentation, and no TIN backend even in PlanetScale’s own public fork of the benchmarker they used. Installation instructions direct you to update your PlanetScale cluster.

So its capabilities cannot be exercised here and its published numbers cannot be reproduced or contested by anyone outside PlanetScale. Adding a TIN column with vendor figures would violate the rule this document is built on — competitor rows reflect what we ran ourselves. An architectural comparison, based on reading their published design in full, is in bench/NOTE_VS_TIN_2026-09-14.md; the short version is that TIN’s headline architectural argument (use ctid as the posting identifier, so merges never renumber) is a design pg_fts already implements, while its two-level bitmap + AVX-512 execution engine is a genuine advantage over our scalar delta-packed postings.

Query capability

Capability pg_fts pg_textsearch pg_search vchord tsvector/GIN
BM25 ranked top-k Yes Yes Yes Yes No (ts_rank is not BM25)
Boolean match predicate (AND/OR/NOT) Yes Yes (1.x: @@ tsquery filter, then sort) Yes No (ranking only) Yes
Exact count(*) of a match set Yes (index-native) Yes, but seqscan (@@; 251 s on 2.19M rows) Yes No Yes (heap/bitmap)
Phrase queries Yes Yes (1.x: <-> filter + recheck) Yes (###) No Yes (<->)
NEAR / proximity with distance Yes No n/t No Yes (<N>)
Prefix terms (term*) Yes Yes (1.x: :* filter) Yes No Yes
Fuzzy terms (Levenshtein) Yes (term~k, DFA) No n/t No No
Regex terms Yes (/re/) No n/t No No
BM25 variants (lucene/robertson/atire/bm25+/bm25l) Yes No No No n/a
BM25F multi-field weighting Yes No n/t No No
Field zones / weighted sections Yes (term:A) No n/t No Yes (setweight)
Highlight / snippet Yes No n/t No Yes (ts_headline)
Index-maintained corpus stats (N, avgdl, df) Yes No public API n/t No No
Lexical anomaly detection Yes No No No No
tsquery migration path Yes (cast + helper) n/a No No n/a

Read: query-language breadth is pg_fts’s widest margin. pg_textsearch 1.x added boolean/phrase/prefix as a @@ tsquery filter over its ranked scan (not index-native, per its own README), and still has no NEAR, fuzzy or regex; vchord is ranking-only by design (no boolean or count support at all); pg_search is the only competitor with comparable breadth.

Correctness and semantics

Property pg_fts pg_textsearch pg_search vchord
Uses PostgreSQL english text-search config Yes Yes No (Tantivy) Yes
English stemming applied Yes Yes No Yes
Match counts agree with the other stemming engines Yes (byte-identical) Yes No (−33% on year) Yes
Exact top-k (verified against a heap sort) Yes (parity_check.sh, 10 cases) n/t n/t n/t
Unverifiable phrase behaviour false (matches PG OP_PHRASE) n/a n/t n/a
MVCC-correct deletes Yes (tombstones) n/t n/t n/t
WAL-logged / crash-safe Yes (all writes via GenericXLog) n/t n/t n/t
Physical-replication safe (failover tested) Yes (t/002) n/t n/t n/t

Read: the stemming row is the important one. pg_search’s speed advantage is partly a different (smaller) unit of work — it does not stem, so year matches 495,580 documents where the correct English answer is 734,896, confirmed by regex on the raw text.

Performance (2.19M Wikipedia articles, identical single column)

Measure pg_fts pg_textsearch pg_search vchord
Index size 1,421 MB 1,887 MB 2,734 MB 2,902 MB
Build time 381 s 496 s 127 s 56 s
rare k10 5.89 ms (fts_search) 7.36 2.13 2.48
mid k10 10.64 7.96 2.04 2.40
common k10 36.16 20.71 2.12 3.49
common k100 46.01 50.71 3.72 24.52
exact count(*) 2.20 ms — 13.63 —
phrase (tuned) 229 ms — 22.9 —

Caution: the pg_fts column above used fts_search(); the competitors used ORDER BY forms (see the retraction in CHANGELOG 1.8.6). And pg_textsearch has since moved. Head-to-head on 2026-09-30, both engines using ORDER BY forms (pg_fts 1.8.6 vs pg_textsearch v1.4.0, same hardware and corpus):

Measure pg_fts 1.8.6 pg_textsearch 1.4.0
rare / mid k10 10.21 / 15.99 ms 0.92 / 1.17
common k10 / k100 49.16 / 50.14 11.41 / 13.75
AND / OR2 / OR3 k10 9.03 / 10.69 / 15.40 37.69 / 36.94 / 31.79
prefix / phrase k10 18.38 / 239 (positions=on) 13.41 / 41.8
exact count(*) 2.50 ms 251 s (seqscan)
saturated tps, rare / common / count 1,050 / 205 / 2,645 8,130 / 640 / –
index size 1,421 MB 1,887 MB

Read: pg_fts wins size, count(*) and multi-term boolean ranked. pg_textsearch 1.4.0 now leads on every single-term ranked query (4-14x) and on prefix and phrase. Both trail pg_search on common-term ranked.

Operational surface

Property pg_fts pg_textsearch pg_search vchord
Requires shared_preload_libraries No (verified: every benchmark/test cluster ran without it, and the FtsCount CustomScan pushdown still fires) Yes Yes Yes
Pure C (no Rust toolchain to build) Yes Yes No (Rust/pgrx) No (Rust/pgrx)
Extra build dependencies none none openblas, pgvector, pgrx pgrx
Incremental maintenance (no REINDEX to add rows) Yes (pending list) n/t n/t n/t
CREATE INDEX CONCURRENTLY Yes (verified) n/t n/t n/t
Parallel index build Yes (faster; no durable size cost) Yes (5 workers, 260 s) n/t n/t
Parallel scan No (built, measured, reverted) n/t n/t n/t
Managed-service safe (replica guard, privileges) Yes n/t n/t n/t
Non-UTF-8 server encodings Yes (fixed 1.5.9) n/t n/t n/t
Big-endian hosts Untested (no CI) n/t n/t n/t

Note on parallel builds (corrected 2026-09-09): an earlier sweep reported a parallel build as ~17% larger than serial. That was measured before fts_vacuum. Re-measured with the vacuum step, serial and 4-worker builds land at identical size (1,420 MB each) with identical match counts — a parallel build is faster and leaves more reclaimable residue, not a bigger index. Run fts_vacuum once after a large build. Details in bench/BENCHMARK_SUMMARY.md.

Read: not needing shared_preload_libraries is a genuine deployment advantage — the other three all require a restart to install, and on a managed service may require provider support. Being pure C also matters: two competitors need a Rust toolchain, and pg_search additionally needs OpenBLAS and pgvector.

Choosing between them

  • pg_fts — you want one index that answers ranked BM25 and boolean, exact counts, phrase, prefix, fuzzy and regex, with PostgreSQL-consistent stemming, the smallest on-disk footprint, and no preload/Rust requirement. Accept slower single-term ranked queries (pg_textsearch 1.4.0 and pg_search are both faster).
  • pg_search — you want the fastest ranked latency across the board and can accept a Tantivy analyzer that does not stem (so results differ from to_tsvector), a 1.9× larger index, and a Rust build.
  • vchord — you want fast ranking and nothing else; it has no boolean or count support, and the largest index here.
  • pg_textsearch — you want the fastest single-term BM25 ranking on top of PostgreSQL’s own analyzer (1.4.0 leads pg_fts 4-14x there). Boolean/phrase/prefix work as a filter over the ranked scan, and there is no index-backed count.
  • tsvector/GIN — already in PostgreSQL, mature tooling, but no BM25 and no index-native top-k.

What this matrix does NOT cover

Three dimensions normally used to judge a BM25 access method are absent, and their absence is not evidence of parity (bench/COVERAGE_AUDIT_2026-09-10.md):

  • Concurrent throughput (QPS) — MEASURED cross-engine 2026-09-11 (bench/RESULTS_C1X_CROSSENGINE_2026-09-11.md), all four engines, one documented query form, same instance type. Headlines: No engine collapses — all four rise to 8 clients then plateau, host-CPU-bound on 16 vCPU / 8 physical cores. pg_fts has the best scaling factor (10.7x rare / 10.0x common, latency flat 1→8) and the worst absolute ranked throughput: at 32 clients 1,076 tps rare (pg_textsearch 8,349) and 208 tps common (pg_search 4,298, i.e. 20.7x — the common-term gap is worse under load than the 17x single-client figure). count(*) is ours by a wide margin: 2,923 tps / 10.9 ms at 32 clients vs pg_search 513 tps / 62.3 ms (5.7x), and pg_textsearch/vchord cannot do it at all. Correction recorded there: an earlier claim that vchord collapses was wrong — it peaks at 8 clients and declines only 4.7-7.2% by 32.
  • Ingest / update throughput. We measure bulk build only. Sustained INSERT rows/s, DELETE/UPDATE cost, and how latency degrades as the pending list grows between merges are unmeasured for every engine.
  • Ranking quality (NDCG / recall vs a reference). We verify our own exactness (top-k parity against an exact sort, gated per release) but have never compared relevance ordering against a rival. This matters here because pg_search does not stem, so it answers a different query.

Caveats on this matrix

Every n/t is a real gap in our knowledge, not an implied “No”. We benchmarked the competitors for latency, size and match counts on one corpus; we did not audit their crash safety, replication behaviour, MVCC correctness or concurrency, all of which pg_fts has been tested for at length (and had bugs found in). A fair reading is that our own rows are better evidenced than the competitors' — including the rows where we lose.