Best Vector Database for RAG in 2026

The best vector database for RAG is usually the one that sits closest to the data you retrieve from and enforces the same permissions: for most apps that is Postgres with pgvector. Pick a dedicated vector database such as Pinecone, Qdrant, Weaviate or Milvus when retrieval volume or collection size outgrows one Postgres server, or when you want built-in hybrid search and reranking without writing SQL. Below are the criteria that matter for retrieval-augmented generation specifically, an honest look at six options, and a hybrid retrieval query you can run today.

#What RAG needs from a vector database

Generic vector benchmarks measure queries per second on a fixed dataset. RAG puts different demands on the store:

1. Permission-aware retrieval. Whatever retrieval returns goes into a prompt. If a user can see a chunk in the answer, they can see it, period. The store must filter by tenant, user or role on every query, without exceptions.
2. Freshness. Users edit and delete documents. A deleted contract that still answers questions for a week is a bug, sometimes a legal one.
3. Metadata filters. "Only this workspace, only documents from 2026, only English" are normal RAG filters, and approximate indexes can return too few results when filters are selective.
4. Hybrid search. Embeddings miss exact terms: product codes, names, error messages. Combining keyword and semantic ranking fixes a large share of bad retrievals.
5. Operational fit. Backups, region, cost at your size, and how many systems your team must run.

Speed matters too, but at the scale of most RAG apps (thousands to a few million chunks), every option here is fast enough. The five points above are where they differ.

#The options at a glance

Prices and free tiers are from each vendor's own pricing page and change often; check before you commit.

#pgvector (Postgres)

Pick it if your app already stores its documents, users and permissions in Postgres.

pgvector adds a vector column type, distance operators and HNSW and IVFFlat indexes. The big RAG advantage is that the embedding is just another column of the row it describes. Delete the document and its chunks go with it (on delete cascade). Write a Row Level Security policy once and every retrieval query respects it. Filter with any SQL, join with any table.

Since version 0.8.0, iterative index scans address the filtered-search problem: with hnsw.iterative_scan on, Postgres keeps reading the index until enough rows pass your where clause. halfvec stores vectors at half precision to save space, and HNSW can index up to 2,000 dimensions for vector and 4,000 for halfvec.

Trade-offs. It runs inside one database server, so a very large index competes with your app for memory. You tune index parameters yourself. Hybrid search is something you write in SQL (example below), not a toggle.

#Pinecone

Pick it if retrieval is your product's core and you want a service you never size or tune.

Pinecone is fully managed. Records live in namespaces, which work well as one-per-tenant isolation; metadata filters use operators such as $eq, $in and $gt on flat JSON metadata (up to 40 KB per record). It has sparse indexes for keyword-style matching, hosted embedding models and reranking, which makes good hybrid retrieval mostly configuration.

Trade-offs. Your vectors live apart from your app data, so you keep them in sync and apply permissions in your own code. Paid plans start at $20/month (Builder) or a $50/month minimum (Standard), and the free Starter plan is limited to AWS us-east-1 (as of November 2026; pricing).

#Qdrant

Pick it if you want a dedicated engine you can also self-host, with strong filtering and memory controls.

Qdrant stores points with a JSON payload you can filter on, supports several named vectors per point, sparse vectors for hybrid search and multivectors. Its quantization options (scalar for 4x compression, binary up to 32x, product up to 64x, per its docs) let large collections fit in less memory. The open-source server is Apache 2.0, and Qdrant Cloud has a free single-node cluster plus usage-based paid tiers (pricing).

Trade-offs. A second system with its own permission model and sync path. Paid cloud pricing is usage-based, so estimate with their calculator.

#Weaviate

Pick it if you want hybrid search and embedding generation built into the database.

Weaviate's hybrid search runs a vector search and a BM25F keyword search and fuses them, with alpha setting the balance (1 is pure vector, 0 pure keyword). Embedding integrations with providers such as OpenAI, Cohere, Google, Mistral and Voyage AI vectorize objects on import. Weaviate Cloud has a free tier, Flex from $45/month and Premium from $400/month (as of November 2026; pricing).

Trade-offs. Again a separate system next to your app database. The data model is objects and classes, not tables, which is a learning curve if your team thinks in SQL.

#Milvus and Zilliz Cloud

Pick it if you plan for very large collections or need specialized index types.

Milvus offers a long list of index types (HNSW, IVF variants, DiskANN, ScaNN and GPU indexes such as GPU_CAGRA) and deploys as Milvus Lite (a Python library), Standalone (one machine) or Distributed (Kubernetes). Zilliz Cloud lists managed Milvus among its services, with a free tier of 5 GB and up to 5 collections and dedicated clusters from $126/month on Standard (as of November 2026; pricing).

Trade-offs. The distributed deployment is serious infrastructure to run yourself. For a few million chunks it is more than you need.

#Chroma

Pick it if you are prototyping in Python and want the shortest path to a working retriever.

Chroma is Apache 2.0 open source and popular in notebooks and RAG tutorials. Chroma Cloud has a Starter plan at $0 plus usage with $5 of monthly credits, and Team at $250/month (as of November 2026; pricing).

Trade-offs. Like the other dedicated stores, permissions and sync with your app data are your job.

#Hybrid retrieval in plain Postgres

This is the query that makes pgvector competitive for RAG: semantic and keyword results merged with reciprocal rank fusion. Add a generated full-text column first:

alter table public.chunks
  add column fts tsvector generated always as (to_tsvector('english', content)) stored;

create index on public.chunks using gin (fts);
create index on public.chunks using hnsw (embedding extensions.vector_cosine_ops);

Then the retrieval function:

create or replace function public.hybrid_chunks(
  query_text text,
  query_embedding extensions.vector(1536),
  match_count int default 5
)
returns table (id bigint, content text, score double precision)
language sql stable
set search_path = public, extensions
as $$
  with semantic as (
    select c.id, row_number() over (order by c.embedding <=> query_embedding) as rank
    from chunks c
    order by c.embedding <=> query_embedding
    limit 20
  ),
  keyword as (
    select c.id, row_number() over (order by ts_rank_cd(c.fts, q) desc) as rank
    from chunks c, websearch_to_tsquery('english', query_text) q
    where c.fts @@ q
    order by ts_rank_cd(c.fts, q) desc
    limit 20
  )
  select c.id, c.content,
         (coalesce(1.0 / (60 + s.rank), 0) + coalesce(1.0 / (60 + k.rank), 0))::double precision as score
  from semantic s
  full outer join keyword k on k.id = s.id
  join chunks c on c.id = coalesce(s.id, k.id)
  order by score desc
  limit match_count
$$;

Each list contributes 1 / (60 + rank) for every chunk it found, so a chunk ranked well by both methods rises to the top, and an exact keyword hit that embeddings missed still makes the cut. The function runs as the caller, so Row Level Security on chunks filters both lists before anything reaches your prompt.

#What about vector databases for AI agents?

Agents add two needs on top of RAG: they write (memories, notes, task state), and they act on their own. A store for agents needs scoped credentials, a log of what the agent did, and a way to undo it. That is an argument for a database with real roles and transactions rather than a pure vector index. See the best database for AI agents for that angle.

#Where StitchDB fits

StitchDB is a hosted Postgres backend, so it is the pgvector option with the rest of the app attached: Auth, a REST API, Edge Functions for calling embedding models, and Row Level Security on the same tables. Enable vector in Studio under Database → Extensions (docs), create your chunks table, and call hybrid_chunks from the client:

const { data, error } = await stitchdb.rpc('hybrid_chunks', {
  query_text: question,
  query_embedding: embedding,
  match_count: 5,
})

If you do not need your own pipeline, the built-in search index does hybrid keyword and semantic search without managing embeddings, with RLS applied; semantic mode is included from the Pro plan.

Honest limits: StitchDB runs only in EU regions (Germany and Finland), it is a younger platform than the vector vendors above, and a very large vector index on a shared server competes with your app; Scale and Enterprise projects can move to a dedicated server.

#FAQ

#Is pgvector good enough for production RAG?

Yes, for most apps. With an HNSW index, iterative scans for filtered queries and hybrid ranking, it handles millions of chunks. Dedicated databases make sense at much larger scale or when you want managed hybrid search.

#Which vector database is fastest?

It depends on dataset, filters, hardware and settings. Vendor benchmarks are run by vendors. Test two candidates on your own chunks and queries.

#Do I need hybrid search for RAG?

Usually it helps. Embeddings miss exact identifiers and rare terms; keyword search catches them. Reciprocal rank fusion is a simple, robust way to combine both.

#How do I keep vectors in sync with documents?

Store them in the same database as the documents, with a foreign key and on delete cascade. With a separate vector store, update it from a queue or trigger on every change.

#What is the cheapest vector database for a side project?

Several have free tiers: Pinecone Starter, Qdrant's free cluster, Weaviate's free tier, Zilliz Free. If you already have a free Postgres project, pgvector costs nothing extra.

Build RAG next to your data: enable vector and start a free project.