Choosing a vector database for RAG: pgvector, Pinecone, Qdrant or Redis?

Picking a vector database for RAG feels like a big architectural decision, and vendors are happy to keep it feeling that way. In practice, for the size of most business knowledge bases, several options work well and the difference between them matters far less than how you chunk, filter and search. Here is how I actually decide.

What a vector database does in RAG

Each chunk of your documents is turned into an embedding — a list of numbers representing its meaning. The vector database stores those embeddings and, given a question’s embedding, returns the closest chunks quickly. Around that core job, the features that matter in production are:

• Metadata filtering — “only this tenant’s documents, only English, only current versions.”
• Hybrid search — combining semantic similarity with plain keyword matching.
• Updates and deletes — keeping the index in sync when documents change.
• Operations — backups, monitoring, access control, cost.

pgvector: start here if you use Postgres

pgvector adds vector columns and similarity search to PostgreSQL. Your embeddings sit next to the rest of your data, in the same backups, with the same permissions, queryable with a normal JOIN.

• Good for: most apps up to millions of chunks, multi-tenant SaaS where filtering by tenant is essential, teams that do not want another service to run.
• Watch out for: index tuning on large datasets, and heavy vector workloads competing with your transactional queries.

Managed Postgres providers like Supabase ship it ready to use. This is my default, and it is the approach behind RAG inside a Laravel app.

Redis: when you already run it and need speed

Redis supports vector search alongside its usual caching and queue roles. If Redis is already in your stack — as it is in most of my Laravel projects — it is a fast, low-friction option for moderate-sized indexes, semantic caching of repeated questions, and agent memory.

• Good for: low latency, semantic caches, short-lived or frequently changing data.
• Watch out for: memory cost on large indexes, and making sure persistence is configured the way you think it is.

Qdrant: a dedicated engine you can self-host

Qdrant is a purpose-built vector database, open source and easy to run in Docker or use as a managed service. Filtering and hybrid search are strong, and it handles larger indexes comfortably.

• Good for: larger or search-heavy workloads, clients who need data to stay on their own servers.
• Watch out for: one more service to deploy, back up and keep in sync with your main database.

Pinecone: fully managed, nothing to operate

Pinecone is a hosted vector database: no servers, scales without tuning, good tooling. You pay for that convenience, and your data lives with a third party.

• Good for: teams with no infrastructure capacity, very large indexes, fast prototypes.
• Watch out for: cost at scale, data residency requirements, and keeping it in sync with your source of truth.

What matters more than the database

Hybrid search

Pure semantic search struggles with product codes, names, error messages and exact phrases. Combining it with keyword search (BM25 or Postgres full-text) and merging the results fixes a large class of “why didn’t it find that?” failures. Whatever you pick, make sure hybrid search is possible.

Filtering before searching

In a multi-tenant system, a filter by tenant id is not an optimisation — it is the security boundary. It must be applied inside the search, not after it.

Re-ranking

Retrieve 20–50 candidates, then use a re-ranking model to pick the best 5. This often improves answers more than switching databases ever would.

Chunking

Bad chunks give bad results in any database. See RAG chunking strategies.

My short decision rule

1. Already on Postgres? Use pgvector.
2. Need a semantic cache or agent memory and have Redis? Use Redis for that part.
3. Outgrown Postgres, or need a dedicated self-hosted engine? Qdrant.
4. No one to run infrastructure and data residency is not a concern? Pinecone.

Then spend the saved time on evaluating your retrieval. If you are planning a RAG system and want an architecture that fits your stack, my AI agents and RAG systems service covers exactly that — get in touch.