FAISS vs Qdrant vs pgvector: choosing a vector store for a student or startup RAG project

Three vector stores I have actually used, compared on setup, filtering, persistence, hosting cost and when each one is the right call for a RAG project.

Presenting to a room
Presenting to a room

Students ask me which vector database to use far more often than they ask how to chunk, which is backwards — but the question deserves a straight answer. I have shipped with FAISS, Qdrant and pgvector. None is universally best; each is best at a stage.

FAISS: the fastest way to start

FAISS is a library, not a server. You build an index in memory, search it in microseconds, and save it to a file. It is perfect for prototypes, hackathons and offline evaluation. Its limits appear the moment you need metadata filtering ("only chunks from this document"), concurrent writes, or an index bigger than your RAM.

Qdrant: a real vector service

Qdrant runs as a service with a clean HTTP API, payload filtering, and persistence out of the box. For document-scoped RAG — a user asks questions about their own uploads only — its filtering is exactly what you need. It is one more container to run, which matters on small hosts; plan the memory budget.

pgvector: vectors next to your data

If your app already has PostgreSQL, pgvector adds a vector column and similarity operators to the database you are already backing up and querying. Joins between chunks and users, documents and permissions become ordinary SQL. It is the choice I reach for when the product has real users and real access control, because one database is easier to operate than two.

A decision table

  • Hackathon or notebook experiment → FAISS.
  • Multi-tenant RAG with per-document filtering and no existing database → Qdrant.
  • Product with users, permissions and PostgreSQL already in place → pgvector.
  • Corpus under 100k chunks and a single server → any of the three; optimise for operational simplicity.

The mistake to avoid

Choosing a vector store before you have an evaluation set. Retrieval quality is decided by chunking, embeddings and hybrid search — not by the database. Pick the store that fits your hosting and data model, then spend your effort on the pipeline in front of it.

RAGVector databaseFAISSQdrantpgvector
Pranjul Rathour
Pranjul Rathour
GenAI Engineer · Kanpur, Uttar Pradesh, India

GenAI engineer and AI product builder with 2+ years shipping production-grade AI systems: RAG pipelines, fine-tuned LLMs, hybrid retrieval and multi-modal apps across vision, speech and OCR, architected end to end from ingestion to deployment. Leads engineering for SCULT INDIA's 14-member team, founded the 500+ member TechVerse Enclave community and has mentored 200+ students. Three hackathon first prizes: Changethon 2025 (IIT Roorkee), Product Genesis at Vividhotsava 2025 (CSJMU Kanpur) and BYTEBATTLE (MeetKats).

Open to GenAI roles, hackathon judging, mentorship sessions and guest talks at colleges. Email pranjulrathour41@gmail.com.

Keep reading

More on RAG & retrieval

All RAG & retrieval posts →
Campus talks · hackathon judging · mentoring

Want this as a live session at your college?

Open to GenAI roles, hackathon judging, mentorship sessions and guest talks at colleges.

Pranjul Rathour, GenAI engineer in Kanpur