pgx-bm25 1.0 adds BM25 as a native PostgreSQL index

PGX Inc. posted on 7 October 2026 that version 1.0 of pgx-bm25 is out. The announcement calls it an extension that adds Okapi BM25 ranked full-text search to PostgreSQL as a native index access method. It supports PostgreSQL 17 and 18, and it installs as bm25_native.

An index access method is the server’s plug for a new index type. Once it is registered, CREATE INDEX ... USING bm25_native builds an index the planner can scan, using the same page format the rest of the database already knows how to log and copy.

What “native” means in this announcement

The news post says: “The whole index lives in the index relation’s own pages, so it gets WAL logging, crash recovery, and physical replication from core.” VACUUM maintains it. “There is no external search engine and no separate runtime to operate.” The extension is written in C, built with PGXS. A C compiler and pg_config are the toolchain the post names.

The README matches the version line: PostgreSQL 17 or 18. It says PostgreSQL 16 is not supported, because that version’s planner cannot order a scan of this kind and then break ties. PostgreSQL 19 is tested against the current beta, the news post says, and “is not yet a supported major version.” The README says the same about 19beta4. CI, the announcement says, builds and tests 17 and 18, including sanitizer runs and TAP tests for crash recovery and replica equality.

Text analysis uses PostgreSQL’s own Snowball dictionaries, with the language set per index, so a search for “negligent” finds “negligence.” Ranked top-N queries use block-max WAND. The post says a typical LIMIT 10 search does not have to score every matching document.

Queries, and what you can change without a rebuild

@@@ selects matching rows. &@@ orders them. The announcement says the query runs as an ordered index scan, with no Sort node.

Multi-column indexes use BM25F: per-field boosts and per-field length normalization. The parameters k1 and b, and the boosts, can be changed with ALTER INDEX ... SET and take effect on the next scan, without a REINDEX. The post also lists exact phrases, proximity by token distance, boolean queries (must, should, must_not), prefix wildcards, query-time boosts, and bm25_snippet(), which is HTML-escaped by default. Simple searches can be a text string. Everything else is built as a jsonb query tree, so user input arrives as a value.

On-disk compatibility is described as a contract. Additive format changes do not require a REINDEX. Where a breaking change allows it, bm25_upgrade() migrates an index in place.

Licence, and who maintains it

The news post says pgx-bm25 is released under the PostgreSQL License, the same terms as PostgreSQL itself. “It is a standalone project: it does not depend on, or connect to, any other product or service, and there is no separate commercial edition.” The LICENSE file is that licence, copyright 2026 PGX Inc. The README names the maintainer as Christophe Pettus.

A short sidebar on pg_fts 1.10.0

The same day, PGXN listed pg_fts 1.10.0 as a stable release under the PostgreSQL License, released by gregburd. It is a different extension. Nothing here ranks it against pgx-bm25.

The 1.10.0 changelog says rare-term ranked throughput no longer falls as concurrent backends increase, that there is no on-disk format change, and that no REINDEX is required. The change is one shared copy of each segment’s document-length array, in dynamic shared memory, instead of a copy in every backend. The changelog puts the old copy at about 4.8 MB per backend at 2.19 million documents.

The throughput figures in that note are the author’s own comparison, on one host: “Same host and binary, Graviton3, shared vs per-backend: rare-term tps at 64 clients 16,654 vs 13,283 (+25%).” Mid-term queries are listed at plus 21 to 25 percent at every client count, common-term at plus 1 to 3 percent, and rare-term throughput is described as flat from 16 to 64 clients. A new setting, pg_fts.shared_doclen, defaults to on. Those numbers are the changelog’s measurement of shared memory against the previous per-backend copy. They are not a comparison with pgx-bm25.