Speak at Bengaluru Systems meet-up

Developers building on PostgreSQL face a painful dilemma: PostgreSQL’s native full-text search lacks BM25 ranking, powerful query composition, and performs poorly at scale (millions or more rows), while Elasticsearch introduces dual infrastructure and complex synchronization (ETL). pg_search eliminates this trade-off with dramatically faster performance for various use cases.

What is pg_search:
It is a Rust-based PostgreSQL extension that provides BM25 relevance ranking, sub-100 millisecond queries over millions of documents, faceted search and aggregations, and hybrid search combining BM25 with vector similarity. It offers full ACID guarantees without requiring separate infrastructure.

Technical Architecture:
pg_search uses PostgreSQL’s official extension hooks instead of forking the database. These include set_rel_pathlist_hook for base table scan interception, create_upper_paths_hook for aggregate planning takeover, and the Custom Scan API for execution path replacement. The extension intercepts ParadeDB search operators and routes search execution to Tantivy, a Rust-based alternative to Lucene, while maintaining full PostgreSQL compatibility.

MVCC Integration:
The Tantivy index is stored in PostgreSQL’s block storage with an MVCC-aware directory. Snapshot-based visibility checking ensures full transactional consistency through extension APIs.

Why This Matters:
pg_search demonstrates that PostgreSQL’s extension architecture can integrate specialized search engines while preserving ACID guarantees. For many Postgres-centric workloads, it can remove the need for a separate Elasticsearch tier, simplifying infrastructure while delivering Elasticsearch-grade search inside PostgreSQL—all without forking PostgreSQL.