ParadeDB

Variations

This product is available in the build below. Open it for the operating system, cloud and version detail, or read its deployment guide.

Overview

ParadeDB's pg_search extension puts a real search engine inside PostgreSQL. It builds a BM25 index, backed by the Tantivy search library, over whichever text columns you choose, and searching is then an ordinary SQL query: a match operator selects the rows and a scoring function returns the relevance score you sort and filter on. Because the index lives in the same database as the data, there is no separate search cluster to operate and no synchronisation pipeline to keep correct, and a search can join to the rest of your schema like any other query.

The extension requires pgvector and so ships with it enabled, which means the same database serves keyword relevance and vector similarity over embeddings side by side, and hybrid retrieval is a single statement. This suits a corpus that fits comfortably in one PostgreSQL where search should be a query against data already stored transactionally: product and catalogue search, log and ticket search, document retrieval for an assistant. It is honestly not a replacement for a multi node search cluster, because it is one database: there is no sharding across nodes and no separate analyzer plugin ecosystem, and serving BM25 searches from a read replica is an upstream Enterprise feature rather than part of the AGPL Community extension this image ships. It is the right answer when a dedicated search tier was only ever there to add ranking to data that already lives in Postgres.

Common uses

• Add relevance ranked search to product, document or ticket data already in PostgreSQL
• Retire a separate search cluster that existed only to rank data the database already holds
• Combine BM25 keyword relevance with pgvector similarity for hybrid retrieval in one query