Provides a full-text-search parser that splits Chinese, Japanese, and Korean text into 2-gram tokens while keeping default behavior for other scripts.

Full-text Search·C·huangjimmy·PG 18, 17, 16, 15, 14, 13, 12, 11

1mo

pg_cjk_parser

400 30d

Provides a full-text-search parser that splits Chinese, Japanese, and Korean text into 2-gram tokens while keeping default behavior for other scripts.

Full-text Search·C

tsvector2

Provides an extended tsvector type with better compression and no 1MB size limit, as a drop-in replacement.

Full-text Search·PostgreSQL·C·postgrespro·PG 10, 11, 12, 13, 14, 15, 16, 17

tsvector2

260 30d

Provides an extended tsvector type with better compression and no 1MB size limit, as a drop-in replacement.

Full-text Search·PostgreSQL·C

What is a PostgreSQL Full-Text Search Extension?

Full-text search extensions go beyond Postgres' built-in tsvector and to_tsquery — they add modern ranking algorithms (BM25, BM25F), faster index types, and richer query syntax. The most prominent is pg_search from ParadeDB, which embeds a Tantivy (Rust) search engine directly in Postgres for sub-100ms relevance-ranked queries over millions of rows. Smaller extensions like pg_bestmatch, prefix, and pg_trgm cover BM25 scoring on heap tables, prefix-matching with GiST indexes, and fuzzy string matching respectively. Together they let teams handle search workloads without standing up Elasticsearch or Meilisearch alongside their primary database.

When to Add a Full-Text Search Extension

Reach for an FTS extension when tsvector ranking falls short — multi-field weighted search, fuzzy/typo tolerance, BM25 relevance, faceted filters, or sub-100ms response over millions of documents. tsvector + ts_rank is fine for blog search and small catalogs (under ~100k docs). pg_search is the upgrade path for product catalogs, document search, and any case where Elasticsearch was the alternative. If you need real-time indexing of arbitrary JSON, distributed cluster scale across regions, or hybrid lexical-plus-vector search beyond what pg_search supports, then Elasticsearch or Meilisearch remain better fits — but most teams can stay on Postgres with pg_search.

Frequently Asked Questions

What's the difference between tsvector and a full-text search extension?

tsvector is Postgres' built-in document type for lexical search — you create a tsvector column, build a GIN index, and query with to_tsquery + ts_rank. It works well for small-to-medium corpora and basic ranking. FTS extensions like pg_search add BM25 (a modern, stronger ranking algorithm), highlighting, faceted filtering, multi-field boosting, and faster index builds via Tantivy. For under 100k documents, tsvector is fine. Above that, pg_search delivers Elasticsearch-grade performance without leaving Postgres.

Should I use Postgres full-text search or Elasticsearch?

Stay on Postgres with pg_search when your search workload is text-only against your primary database — you get one auth model, one backup story, one transactional boundary. Move to Elasticsearch when you need: cross-cluster replication across regions, sub-50ms search at high QPS over tens of millions of docs, real-time indexing of arbitrary JSON schemas, or built-in features like learned-to-rank and percolators. For 90% of B2B SaaS product search, pg_search is enough and significantly simpler to operate.

What is BM25 and why does it matter?

BM25 (Best Matching 25) is the relevance-ranking algorithm used by Elasticsearch, Lucene, and most modern search engines — it considers term frequency, inverse document frequency, and document length normalization to score how well a query matches each document. It's significantly more relevant than Postgres' default ts_rank for natural-language queries. pg_search and pg_bestmatch implement BM25 inside Postgres, giving you Elasticsearch-quality ranking without leaving the database.

How do I install pg_search?

On managed services: pg_search is currently available via ParadeDB's managed offering or self-hosted Docker images — AWS RDS, Supabase, and Neon do not yet ship pg_search in their default extension allow-lists (check the latest docs). On self-hosted Postgres: use ParadeDB's Docker image (paradedb/paradedb) for the simplest setup, or build from source against your existing Postgres install. After installation, run CREATE EXTENSION pg_search; and create a BM25 index with CREATE INDEX ... USING bm25.

Does pg_search work on managed Postgres (RDS, Supabase, Neon)?

Currently no. pg_search requires a shared library and isn't in the default extension allow-lists of major managed providers. ParadeDB offers its own managed service, or you can self-host with their Docker image. AWS RDS, Aurora, Supabase, and Neon support tsvector + GIN out of the box (good enough for most cases), pg_trgm for fuzzy matching, and Aurora/Neon support some additional ranking via pg_bestmatch on certain versions — check the provider's current extension list.

Manage PostgreSQL Visually

1bench is a modern GUI client for PostgreSQL — install extensions, write queries, and inspect schemas without leaving the IDE.

Try 1bench for PostgreSQL