Vector Search in Postgres: HNSW Speed Is Only Useful When the Right Results Survive

A faster query can answer a different question

Vector search turns a similarity problem into a numerical retrieval problem. A system represents items with vectors, then looks for nearby representations. As a collection grows, scanning every candidate can become expensive, so approximate indexes become attractive. The important consequence is that optimization may change which results appear. This differs from the expectation many developers bring from conventional database indexes, where an index is often treated as a faster route to the same logical answer.

The official pgvector documentation distinguishes exact search from approximate approaches and documents HNSW and IVFFlat. It describes HNSW as a graph-based index and explains configuration and filtering considerations. These are the factual anchors for this guide. The article does not claim a benchmark result, recommend a universal parameter value, or assert that one index is best for every dataset. Its purpose is to explain how to evaluate a vector-search design against the actual retrieval job rather than a speed figure alone.

Define relevance before choosing the index

Consider a hypothetical support portal that searches product manuals. A user asks how to reset a device, but the collection contains several generations of that device. A semantically similar passage from the wrong generation may be a poor result even if the vector distance is small. The useful retrieval objective includes product identity, version, language, and the user’s access rights. Those conditions should be part of the evaluation set. A search system that ignores them can look accurate on generic questions while failing the questions customers actually ask.

Create a small set of representative queries with reviewed relevant results. Include easy paraphrases, ambiguous product names, exact identifiers, and questions with no suitable answer. For a larger collection, supplement this set with sampled production queries after removing or protecting personal information. The evaluation does not need to declare one perfect answer to every question, but it needs enough structure to reveal when a faster configuration consistently misses an important class of documents. Otherwise, tuning becomes an exercise in optimizing what is easiest to measure.

Filters can expose a hidden retrieval problem

A similarity query may also restrict results to a tenant, a language, a date range, or an authorized audience. Depending on how the query and index are executed, the system can inspect promising neighbors and then find that many do not satisfy the filter. The final result set may be smaller or less representative than expected. This is not merely a user-interface issue that can be fixed by asking the language model to write a better answer. The evidence never reached the answer stage.

Test selective filters explicitly. A collection with one dominant tenant and many small tenants can behave differently from a balanced collection. A search for current documents can behave differently from one that accepts the entire archive. Inspect the database’s actual execution behavior for the supported version and extension configuration. If the application needs strict isolation among tenants, preserve that authorization requirement while exploring indexing and data-layout options. Search completeness is important, but it cannot justify exposing another tenant’s records as convenient candidates.

Use an exact baseline to understand approximation

An exact-search baseline is useful because it provides a reference for the numerical nearest neighbors under the selected distance function. It does not prove that those neighbors are relevant to a person, but it helps separate index approximation from embedding quality. If approximate search misses a result that exact search finds, index configuration is a plausible place to investigate. If both methods return the wrong product generation, the problem may lie in representation, metadata, query construction, or the definition of relevance.

Keep these evaluations separate in the report. Numerical recall against an exact baseline answers one question. Human relevance answers another. End-to-end answer usefulness answers a third. Combining them into a single accuracy number can conceal where the system fails. A team can then spend resources increasing index recall when the main issue is that the embedding model does not distinguish a crucial identifier. A clear baseline helps direct engineering effort toward the stage that actually limits the experience.

Updates and memory belong in the comparison

Search collections are rarely static. Documents are added, removed, corrected, and re-embedded. An index that performs well immediately after construction may impose different costs under continuous updates. Build time, memory consumption, maintenance behavior, and operational headroom should therefore appear beside query latency. A configuration that fits comfortably in a test environment can become difficult to operate when several replicas or additional indexes are needed. The relevant budget is the whole service, not a single isolated query.

Embedding changes deserve particular care. Vectors produced by different model versions are not automatically interchangeable. A migration may require storing version metadata, rebuilding representations, and testing search quality before switching traffic. Keep the original documents linked to their vectors so the system can explain and refresh its evidence. A vector without a traceable source may still be searchable, but it is difficult to audit, correct, or remove reliably. Retrieval quality and data governance meet at that source relationship.

For each candidate configuration, record the collection size, vector dimensions, distance function, filter distribution, update rate, and hardware. Include the result count and retrieval quality, not just the fastest successful response. If a test excludes index construction or maintenance, say so. These details allow another engineer to understand whether the result applies to a growing support portal or only to the fixed collection used during the experiment.

Choose the configuration that serves the question

A practical decision can begin with exact search on a bounded dataset, then introduce approximation when measured demand justifies it. The appropriate point depends on the workload and budget. Some applications may remain well served by a simple design, while others need more sophisticated indexing, partitioning, or retrieval stages. Complexity should have a measured purpose. It is easier to maintain a system whose additional components each solve an observed problem than one assembled from every available optimization.

HNSW can be a useful part of a Postgres-based retrieval architecture, especially when a team values keeping vectors close to transactional metadata. Its speed matters only in relation to the results the application needs. Evaluate the full query, preserve authorization, compare against a meaningful baseline, and measure the cost of keeping the collection current. The final question is whether the right information reaches the user within the service’s limits. A quick answer built from the wrong neighbors is still the wrong answer.