Skip to content
← Back to blog

Data

PostgreSQL 18 and hybrid search: text and vectors together

When to combine lexical retrieval, pgvector and reranking without creating an unnecessary data platform.

Published on March 15, 20269 min read
PostgreSQL 18pgvectorRAG

Semantic search finds conceptual similarity while lexical search preserves exact terms, codes and names. Hybrid retrieval combines candidates from both before optional reranking.

pgvector supports exact search plus HNSW and IVFFlat. HNSW often offers a stronger speed-recall tradeoff at the cost of memory and build time, and it must be measured with real filters.

Editorial visual

Hybrid retrieval pipeline

Ranking fusion

Text

Terms, names and codes

Vectors

Conceptual similarity

RRF fusion

Combine ranks

04

Final ranking

Permissions and relevance

Two retrievers produce complementary candidates; fusion and reranking create one shared list.

PostgreSQL 18 improves I/O, indexing and observability around these workloads, but quality still depends on embeddings, partitioning, updates and relevance metrics.

Keeping text, permissions, metadata and vectors in PostgreSQL often reduces synchronization and operational surface until scale proves a specialist engine is needed.

Separate retrieval and ranking

The first stage seeks broad coverage and returns candidates. The second combines signals and orders them. This separation reveals whether the problem lives in embeddings, lexical queries, filters or reranking. It also avoids asking an expensive model to inspect documents that never belonged in the candidate set.

Choose indexes with real filters

HNSW and IVFFlat behave differently under memory, updates and tenant filters. Benchmarks need real distributions, languages and permissions. A fast index that loses relevant documents after filtering misses the product goal even when its isolated latency looks excellent.

Fuse without calibrating incompatible scores

Reciprocal Rank Fusion combines positions without assuming text scores and vector distance share a scale. Weights can vary by query type. Exact codes favor lexical search; conceptual questions often benefit more from semantic signals.

Measure quality, latency and operations

Use a query set with relevance judgments and metrics such as recall, MRR or nDCG beside p95 and cost. Monitor index growth, vacuum, embedding updates and permission consistency. Search is a product capability, not one isolated query.

A database before a platform

PostgreSQL can solve hybrid search with less synchronization and consistent permissions. A specialist engine should be introduced after measuring real limits, not before proving that added complexity buys a relevant improvement.