Scalable Hybrid Search in Go: Merging pgvector HNSW and Full-Text Search with RRF Under High Ingestion

Modern search architectures increasingly demand both semantic relevance and exact lexical precision. While dedicated vector databases are popular, combining PostgreSQL’s pgvector extension with native Full-Text Search (FTS) provides an exceptionally robust, single-store alternative. By pairing Hierarchical Navigable Small World (HNSW) indexes for dense semantic retrieval with GIN-indexed tsvector columns for sparse keyword matching, engineers can achieve state-of-the-art retrieval accuracy directly in relational storage without synchronizing multiple databases.

The Rank Fusion Challenge: Why RRF Matters

Merging vector similarity scores (such as cosine distance) with lexical relevance metrics (such as ts_rank) presents a fundamental scoring mismatch: raw distance scores and BM25-style scores inhabit completely different distributions and cannot simply be summed. Reciprocal Rank Fusion (RRF) resolves this problem by operating strictly on the positional rank of search hits rather than their raw scores. Using the standard formula RRF_Score = SUM(1 / (k + rank)), where k is typically set to 60, RRF dampens the influence of outliers and reliably promotes documents that appear near the top of both retrieval models.

Executing Concurrent Hybrid Queries in Go

In a Go application, optimal query latency requires fanning out the vector search and full-text search concurrently over a connection pool configured with pgx/v5. Utilizing Go’s golang.org/x/sync/errgroup alongside standard context timeouts allows both queries to run against PostgreSQL in parallel. Once the top-N results from both queries return, an in-memory RRF aggregation algorithm merges the candidate sets into a single ranked slice. This approach shifts score normalization out of the database engine and into Go's lightweight runtime, minimizing execution overhead and query complexity on PostgreSQL.

Taming HNSW Lock Contention Under High Write Concurrency

The primary architectural bottleneck surfaces under high write concurrency. Unlike inverted indexes, modifying an HNSW graph requires traversing and updating multi-layer neighbor lists, which introduces heavy lock contention and write amplification during continuous ingestion. When combined with synchronous GIN index maintenance for text search, write performance can drop precipitously. Mitigating this issue requires a disciplined ingestion pipeline:

• Batched Ingestion: Buffer incoming records in Go memory channels and flush them in micro-batches using pgx.CopyFrom rather than single-row INSERT statements.
• Tuning Index Construction: Balance vector recall and write throughput by calibrating m and ef_construction parameters to avoid oversized graph connectivity during continuous updates.
• Decoupling Write Paths: Stage high-frequency writes in unindexed tables or read-optimized buffers, updating FTS vectors via background workers or asynchronous triggers.

By pairing Go's high-efficiency concurrency primitives with PostgreSQL's dual indexing capabilities, you can build a resilient, production-ready hybrid search engine. This design sustains thousands of concurrent ingest operations while consistently serving low-latency, semantically rich search results without the operational complexity of an external search cluster.