Vector Databases Explained: ANN, HNSW, Hybrid Search & RAG

Vector Databases Explained: Indexes, Filtering, Hybrid Search, and When You Need One

Vector databases are often described as “databases for embeddings.” That is technically true, but it hides the engineering decisions that matter.

A production vector-search system has to answer much harder questions:

Should search be exact or approximate?
Which similarity metric matches the embedding model?
How much recall can be traded for latency?
What happens when every query includes metadata filters?
Should lexical BM25 search be combined with vectors?
How should tenants be isolated?
Do you actually need a dedicated vector database, or is Postgres/Elasticsearch already enough?

This guide explains those decisions without assuming that a specialized vector database is always the answer.

What Is a Vector Database?

A vector database stores and searches numerical representations called vectors or embeddings.

An embedding model converts content into a fixed-length vector:

"refund policy for annual plans"
        ↓
embedding model
        ↓
[0.18, -0.07, 0.42, ...]

Content with similar meaning should be located near each other in that vector space.

That enables use cases such as:

semantic search
retrieval-augmented generation (RAG)
recommendations
image similarity
duplicate detection
anomaly matching
agent memory retrieval
multimodal search

The database's job is not to understand language itself. The embedding model creates the representation; the database stores, filters, indexes, and searches it efficiently.

Exact Search vs Approximate Search

The simplest vector search compares a query vector against every candidate vector and returns the closest results.

That is exact nearest-neighbor search.

Conceptually:

query vector
   ↓
compare against every eligible vector
   ↓
sort by distance
   ↓
top K

Exact search gives the true nearest neighbors, but its cost grows with the number of vectors examined.

For larger collections, systems commonly use approximate nearest-neighbor (ANN) indexes. ANN avoids scoring every vector by searching a much smaller candidate region.

The trade-off is important:

Exact search
→ highest recall
→ more work as dataset grows

ANN search
→ much lower search cost
→ may miss some true nearest neighbors

The question is therefore not “is ANN accurate?”

The better question is:

> Does the ANN configuration meet the recall target required by the product at the latency and cost you can afford?

Recall Is the Metric Most Teams Forget

Suppose exact search says the correct top 10 documents are:

A B C D E F G H I J

Your ANN index returns:

A B C D E F G H X Y

Eight of the true top ten were found.

That is roughly the intuition behind recall@10.

A faster query is not an improvement if it stops retrieving the documents your RAG system needs.

Benchmark both:

latency
throughput
recall/relevance

Infrastructure performance and retrieval quality must be measured together.

HNSW: Graph-Based ANN Search

HNSW—Hierarchical Navigable Small World—is one of the most common ANN index families.

It builds a graph connecting nearby vectors. Search enters the graph and follows promising neighbors instead of scanning the complete dataset.

At a high level:

query
  ↓
enter upper graph layer
  ↓
navigate toward nearby region
  ↓
descend layers
  ↓
explore local candidates
  ↓
top K

HNSW is popular because it can provide an excellent latency/recall trade-off.

But that performance has costs:

additional memory
index-build time
graph maintenance
tuning parameters that affect recall and latency

For example, pgvector's official documentation describes HNSW as having a better query-performance trade-off than IVFFlat while requiring slower builds and more memory.

So “use HNSW” is not a complete design decision. You still need to size and benchmark it.

IVF: Partition the Vector Space First

IVF-style indexes divide vectors into clusters or lists.

At query time, the system finds the most relevant clusters and searches only a subset of them.

all vectors
   ↓
cluster into lists
   ↓
query selects nearby lists
   ↓
search candidates in those lists

Search fewer lists and queries become cheaper but can lose recall.

Search more lists and recall improves but latency rises.

pgvector's IVFFlat implementation exposes this directly through list and probe tuning.

IVF can use less memory and build faster than HNSW in some implementations, but it typically requires more careful tuning and training/data-distribution awareness.

Similarity Metric Must Match the Embedding Model

Common vector metrics include:

cosine similarity/distance
inner product / dot product
Euclidean (L2) distance

These are not cosmetic choices.

The embedding model may be trained or documented around a particular similarity function and normalization strategy.

Always verify the model's recommendation.

Also remember that the stored vector and the query vector must be compatible:

same embedding model family
same dimension
same representation assumptions

Comparing vectors from unrelated embedding spaces produces meaningless rankings even if the database accepts the numbers.

Metadata Filtering Is Where Benchmarks Become Real

Most vector benchmarks show queries over an unfiltered collection.

Most production applications do not work that way.

A multi-tenant RAG query may actually mean:

find semantic matches
WHERE tenant_id = 42
AND language = 'en'
AND source_type = 'policy'

An e-commerce query may mean:

find semantically similar products
WHERE category = 'laptop'
AND in_stock = true
AND price &lt; 100000

Filtering can dramatically change ANN behavior.

Different systems combine filters with vector search differently:

pre-filtering
filtering during ANN traversal
post-filtering
adaptive combinations of these approaches

OpenSearch, for example, documents efficient kNN filtering that applies constraints during vector search for supported engines. Elasticsearch similarly integrates filters with approximate kNN and can change execution behavior depending on how selective a filter becomes.

The practical rule:

> Benchmark filtered queries using the same selectivity distribution you expect in production.

An index that performs brilliantly without filters may behave very differently when only 0.1% of records are eligible.

Vector Search Is Not a Replacement for Keyword Search

Dense embeddings are excellent at semantic meaning.

They can understand that:

"recover access to my account"

is related to:

"reset forgotten login credentials"

But exact lexical search is often stronger for:

ERR_AUTH_0042
SKU-99182
RFC 9110
PostgreSQL 18
invoice_8871

That is why modern search systems increasingly use hybrid retrieval.

Hybrid Search: Semantic + Lexical

A typical hybrid pipeline looks like:

Query
  ├── dense vector retrieval
  └── lexical/BM25 retrieval
             ↓
       rank fusion
             ↓
       optional reranker
             ↓
          final results

Elasticsearch's current vector-search documentation explicitly supports combining keyword, nearest-neighbor, sparse learned retrieval, and reranking in the same workflow.

Dedicated vector databases such as Qdrant, Weaviate, Milvus, and Pinecone also expose different hybrid retrieval patterns.

For many RAG systems, hybrid search is a better baseline than “embedding search only.”

Reranking Separates Candidate Retrieval From Final Relevance

ANN search is optimized to find a useful candidate set quickly.

A more expensive reranker can then score only those candidates with a stronger relevance model.

millions of records
      ↓
ANN / hybrid retrieval
      ↓
100 candidates
      ↓
cross-encoder / reranker
      ↓
10 final results

This is often more efficient than trying to make the vector index itself solve final relevance perfectly.

Measure whether reranking actually improves user/task outcomes before paying its latency and inference cost.

A Vector Database Is Still a Database

Embedding systems need ordinary data-engineering discipline.

A record often includes:

id
vector
document_id
tenant_id
source
language
created_at
permissions

You still need to think about:

primary identifiers
metadata types
filters
updates/deletes
backups
retention
multi-tenancy
consistency
observability
migrations

The word “vector” does not remove these responsibilities.

Multi-Tenancy Must Be Designed Explicitly

There are several common patterns.

Shared collection/index + tenant filter

one dataset
WHERE tenant_id = authenticated tenant

Advantages:

operationally simple
good for many small tenants

Risks:

authorization filter must never be omitted
shared ANN structures can create noisy-neighbor or recall behavior depending on implementation

Namespace / partition per tenant

Some vector systems expose namespaces, partitions, or tenant-specific index structures.

Advantages:

stronger logical isolation
queries can search less unrelated data

Trade-offs:

many tiny partitions/indexes may carry overhead

Dedicated collection/index per tenant

Useful for large or highly isolated customers, but often too expensive for thousands of small tenants.

The correct pattern depends on tenant count, tenant size distribution, isolation requirements, and the chosen engine.

Authorization must always be enforced by trusted server-side code.

Embedding Changes Are Database Migrations

Changing an embedding model is not equivalent to changing an API configuration string.

A new model can change:

vector dimension
semantic geometry
retrieval quality
cost
latency

Do not mix incompatible model outputs in the same searchable vector field.

A safer migration:

old embeddings remain live
        ↓
generate new embedding representation
        ↓
backfill corpus
        ↓
build index
        ↓
evaluate recall/relevance
        ↓
shadow or canary traffic
        ↓
switch production
        ↓
retire old representation

Version the embedding model in your data pipeline.

Chunking Can Matter More Than the Vector Database

For RAG, retrieval quality often fails before the vector query even runs.

Bad chunking can:

split important context
combine unrelated topics
create too many tiny records
hide headings and document structure

Evaluate chunking by document type.

Code, contracts, support docs, PDFs, database schemas, and product catalogs rarely deserve exactly the same chunking strategy.

A better vector index cannot recover information that was poorly represented during ingestion.

Dedicated Vector Database vs Postgres + pgvector

If your application already uses PostgreSQL, pgvector can be a very strong starting point.

Its official implementation supports:

exact nearest-neighbor search by default
HNSW
IVFFlat
multiple distance functions
normal SQL filters and joins
partitioning
transactions and relational constraints around vector data

This can be ideal when:

vectors belong closely to relational records
traffic is moderate
one database simplifies operations
transactional consistency with application data matters

A dedicated vector database becomes more compelling when vector retrieval itself needs independent scaling, specialized hybrid/search features, very large vector collections, or different operational characteristics from the primary transactional database.

Do not introduce a second database until its benefits outweigh its operational cost.

Vector Database vs Elasticsearch/OpenSearch

If your product already depends heavily on full-text search, Elasticsearch or OpenSearch may provide a natural path because vector search can live alongside:

BM25 lexical retrieval
filters
facets
aggregations
analyzers
existing search infrastructure

Current Elasticsearch documentation supports dense/sparse vectors, approximate kNN, exact vector scoring, hybrid search, filters, and multi-stage retrieval patterns.

OpenSearch similarly exposes kNN engines, HNSW/IVF options, and filtered vector search.

This can be preferable when vector search is one signal inside a broader search product rather than the entire data platform.

Dedicated Vector Database vs Search-Enabled Primary Database

Use the simplest architecture that meets your requirements.

Start with your existing database when:

the vector dataset is modest
search traffic is moderate
operational simplicity matters
vectors need transactional joins with core data
existing vector functionality meets latency/recall goals

Evaluate a dedicated vector database when:

vector search must scale independently
vector collections are extremely large
advanced hybrid/multi-vector/reranking features are core requirements
retrieval traffic dominates the workload
specialized tenant/sharding/index behavior materially helps

The “best vector database” is a workload decision, not a universal ranking.

Disk, Memory, and Compression Matter

Vector storage grows quickly.

A rough uncompressed dense-vector payload alone is approximately:

number_of_vectors × dimensions × bytes_per_value

A million 1,536-dimensional float32 vectors contain billions of numeric values before counting:

index structures
metadata
replicas
database overhead
temporary work
backups

That is why many systems support:

half-precision vectors
scalar quantization
product quantization
binary quantization
disk-backed indexes

Compression reduces cost, but may change recall, CPU usage, or query behavior.

Benchmark quality before and after compression.

Consistency and Freshness Affect the Product

Distributed vector systems may expose different read consistency guarantees.

This matters when the workflow is:

user uploads file
      ↓
embedding/upsert succeeds
      ↓
user immediately asks a question

If retrieval is eventually consistent, the newest chunks may not be visible immediately.

Your application may need:

an indexing state
read-after-write routing
session consistency
readiness checks
retry logic

Do not promise “ready to search” before the retrieval system can actually see the data.

Evaluate Search With Real Queries

Do not choose a vector database from vendor throughput charts alone.

Build a representative evaluation set containing:

real user queries
difficult exact-token queries
semantic paraphrases
tenant filters
restrictive metadata filters
long-tail queries
multilingual queries if relevant

Measure:

recall@K
precision@K
nDCG
mean reciprocal rank
p50/p95/p99 latency
throughput
memory/storage
cost per query
downstream task success

For RAG, the best metric may ultimately be whether the correct supporting evidence reaches the model.

Monitor Relevance Like an Operational Metric

A vector system can remain online while quality silently regresses.

Infrastructure monitoring should include:

query latency
error rate
CPU/memory
storage growth
indexing/backfill lag
replica/shard health

Retrieval monitoring should include:

recall/relevance sample scores
zero-result rate
filter failures
reranker lift
quality after model/index migrations

Treat retrieval quality changes like performance regressions.

Common Mistakes

Choosing a database before defining the workload

Start with query patterns, filters, scale, and consistency requirements.

Benchmarking only unfiltered ANN

Real applications usually filter.

Assuming vectors replace keyword search

Exact identifiers and rare terms still matter.

Using the same embedding forever

Models change. Build migration paths.

One collection per tiny tenant

This can create unnecessary index and operational overhead.

Ignoring recall

Latency without relevance is a failed search system.

Adding a specialized database too early

Operational complexity is also a cost.

Production Checklist

Final Takeaway

Vector databases solve an important problem: searching high-dimensional representations efficiently while combining them with application metadata and production data-management needs.

But there is no rule that every AI application needs a dedicated vector database.

Start with the retrieval workload:

scale
+ filters
+ latency
+ recall
+ hybrid search
+ tenant isolation
+ operations

Then choose the simplest engine that meets those requirements.

Sometimes that is pgvector inside PostgreSQL. Sometimes it is Elasticsearch/OpenSearch. Sometimes retrieval becomes large and specialized enough that a dedicated vector database such as Milvus, Qdrant, Weaviate, or Pinecone is the right subsystem.

The technology should follow the retrieval problem—not the other way around.

References

Tags:Vector DatabaseVector SearchHNSWHybrid SearchRAGEmbeddingsSearch Infrastructure

AI & AGENT ENGINEERING

BUILDING AN AI PRODUCT?

Talk to Lofingo about custom autonomous AI agents, enterprise workflow automation, and scalable software systems.

EXPLORE AI SERVICES →