Replacing Elasticsearch in PostgreSQL with ParadeDB pg_search — A Practical Guide to Implementing BM25 Full-Text Search and pgvector Hybrid Ranking in a Single Query

| Write Performance | 10x write throughput improvement after background merging was introduced in v0.20.0 (see release notes for detailed conditions) | | Korean Language Support | Korean morphological analysis available via korean_lindera (KoDic) and icu tokenizers |

Disadvantages and Limitations

Item	Details
Massive-Scale Distributed Search	Elasticsearch still leads in distributed sharding and replication at the billions-of-documents scale
High-Concurrency, High-Load	Overall TPS is lower than Elasticsearch with 50+ concurrent clients (Tembo benchmark; see source for detailed conditions)
Over 100 Million Vectors	Performance disadvantage vs. Qdrant and Milvus due to pgvector's structural limitations (using pgvectorscale in parallel is a mitigation)
Cross-Encoder Reranking	No built-in trained reranker; high-precision reranking must be implemented separately at the application layer
PostgreSQL 15+ Requirement	Official support is PostgreSQL 15 and above
Cannot Fully Replace the Elastic Stack	If you are using Kibana, Logstash, APM, etc. as a whole, only the search portion is replaced

Application Patterns by Scenario

Scenario	Key Combination	Benefits
SaaS document / issue search	BM25 alone	ETL pipeline elimination, ACID guarantee
E-commerce product search	BM25 + behavioral embedding RRF	Simultaneous keyword + preference matching
RAG pipeline	BM25 + chunk embedding RRF	Improved context quality
Real-time log search	BM25 alone with immediate indexing	Eliminates refresh_interval delay

---

Closing Thoughts

• pg_search provides Tantivy-based BM25 as a native PostgreSQL index, enabling real-time full-text search without ETL.
• Hybrid search combining pgvector and RRF lets you achieve both keyword precision and semantic understanding in a single database query.
• For teams with tens of millions of rows or fewer who are already running PostgreSQL, this is the most practical path to replacing Elasticsearch.

If you want to get started right away, here is the recommended sequence:

1. Verify your environment and enable the extensions — Run CREATE EXTENSION pg_search and CREATE EXTENSION vector on a PostgreSQL 15+ instance. If you are using Neon, it is done in a single line.

2. Add a BM25 index to an existing table — Create the index with USING bm25 (...) WITH (key_field = 'id') and use the @@@ operator to replace your existing LIKE or tsvector searches. You can immediately inspect ranking scores with paradedb.score().

3. Add an embedding column and introduce RRF queries — Add an embedding vector column to a text column and apply hybrid ranking using the FULL OUTER JOIN pattern. You will directly observe results that previously matched only by keyword now expanding to include semantically similar documents.

Looking at the customer case studies published on the ParadeDB official site (paradedb.com), it is already in use across multiple production environments, and as of v0.24.2, stability has been sufficiently validated. The fastest way to form a judgment is to attach an index to a single small table in your development environment and run a @@@ query to see paradedb.score() output directly.

---

References

• ParadeDB Official Documentation
• pg_search GitHub Repository
• ParadeDB Blog: Introducing pg_search Elastic-Quality Full Text Search
• ParadeDB Blog: Hybrid Search in PostgreSQL — The Missing Manual
• ParadeDB Blog: Full Text Search over Postgres — Elasticsearch vs. Alternatives
• ParadeDB Blog: Deep Dive into ParadeDB's v2 API
• ParadeDB Blog: Teaching Postgres to Facet Like Elasticsearch
• ParadeDB Blog: Postgres as a Recommender Engine
• ParadeDB: BM25 Implementation Learning Guide
• Neon: Comparing Native Postgres, ElasticSearch, and pg_search for Full-Text Search
• Neon Docs: The pg_search extension
• Tembo: Benchmarking ParadeDB's pg_search
• ParadeDB 0.20.0 Release Notes
• ParadeDB Tokenizers Documentation
• DEV.to: Hybrid Search in 100 Lines — BM25 + pgvector with RRF Merge
• TigerData: Elasticsearch's Hybrid Search, Now in Postgres
• ParadeDB: pgvector Limitations
• DeepWiki: paradedb/paradedb Architecture Analysis