Four vector stores, four different jobs.
FAISS is an in-process library for nearest-neighbour search; pgvector adds vector columns and indexes to Postgres; Qdrant is a standalone vector search server; Pinecone is a fully hosted service. None of them creates embeddings; you bring those from an embedding model. For most products I start with pgvector and move only when scale or features demand it.
- FAISS
- Library, in memory, no server
- pgvector
- Postgres extension, SQL plus vectors
- Qdrant
- Self-hosted server, rich filtering
- Pinecone
- Hosted, managed, paid
- 5production AI apps
- 14engineers led
- 200+students mentored
Questions students ask
The vector store questions searched most, answered from running retrieval in production.
What is FAISS vector database?
FAISS (Facebook AI Similarity Search) is an open-source C++ library with Python bindings, from Meta's research group, for efficient similarity search over dense vectors. You give it a matrix of vectors, choose an index type (flat for exact search, IVF or HNSW for approximate search, with optional quantisation to save memory), and query it with another vector to get the nearest neighbours and their distances. It is extremely fast and widely used in research and in RAG prototypes. Calling it a database stretches the word, as the next answer explains.
Is FAISS a vector database?
Strictly, no. FAISS is an index library: it searches vectors in memory inside your process. It has no server, no network API, no authentication, no concurrent writers, no metadata filtering of its own, and persistence is you writing the index to a file. A vector database adds all of those: storage, filtering, updates, replication, access control. FAISS is the engine many databases could have inside; it is a superb choice for a notebook, a batch job, a single-machine app or an evaluation harness, and the wrong choice when several services need to read and write the same index.
Does FAISS create embeddings?
No. FAISS only stores and searches vectors you already have. The embeddings come from an embedding model: an open sentence-transformer model running locally, or a hosted embedding API. The usual pipeline is: chunk text, run each chunk through the embedding model to get a vector, add the vectors to a FAISS index, and keep a parallel list mapping each index position back to the chunk text and metadata. At query time you embed the question with the same model and search. Mixing embedding models between indexing and querying produces meaningless distances, so pin the model.
Is FAISS in memory vector database?
FAISS indexes live in RAM (or GPU memory) while in use. You can save an index to disk and load it back, and some index types support memory-mapped storage so a large index can be read from disk, but search assumes the working set is in memory. That is the source of its speed and its main limit: an index of ten million vectors at 1,024 dimensions in full precision needs tens of gigabytes, so at that scale you either quantise, shard, or move to a database that manages memory and disk for you. For the few hundred thousand chunks most products have, a laptop is fine.
Difference between faiss-cpu and faiss-gpu
They are two builds of the same library. faiss-cpu runs on the processor and is the one to install on a laptop, a server without a GPU, or any environment where simplicity matters; it is fast enough for most retrieval workloads. faiss-gpu moves index building and search onto NVIDIA GPUs, which pays off when you build very large indexes, run huge batch queries, or do nearest-neighbour search as part of training. The GPU build has stricter installation requirements (matching CUDA versions, usually via conda). Start with the CPU build; switch only if a measured bottleneck says so.
How to install FAISS in Python
In a virtual environment, install the CPU build with pip; the package name is faiss-cpu and it ships prebuilt wheels for Windows, macOS and Linux. For the GPU build, use conda from the pytorch channel so the CUDA version matches your driver. Verify with a three-line test: create a flat index with the dimension of your embeddings, add a random matrix, search for one vector. Pair it with a sentence-transformer model for embeddings and you have a complete local semantic search in under twenty lines. On Apple Silicon the CPU build works well; GPU builds are NVIDIA only.
What is FAISS in LangChain?
LangChain wraps FAISS as one of its vector store integrations. You pass it documents and an embedding model, it embeds them, builds the FAISS index and keeps the text and metadata alongside; you then call similarity search, use it as a retriever in a chain, and save or load the store from a folder. The wrapper adds the metadata bookkeeping FAISS lacks and makes swapping to another store a one-line change. It also adds the same abstraction layers as the rest of LangChain, so if a search behaves oddly, drop down to the raw index to see what is happening.
Does pgvector create embeddings?
No. pgvector adds a vector column type, distance operators and index types (IVFFlat and HNSW) to Postgres; the vectors themselves come from your embedding model, inserted like any other column value. What you gain is everything Postgres already does: transactions, joins, metadata filtering in the same WHERE clause as the vector distance, backups, access control, and one database instead of two. For most applications under a few million chunks it is the choice I recommend, because the operational simplicity outweighs the raw speed advantage of dedicated engines. Some extensions and services add in-database embedding generation, but plain pgvector does not.
What is Qdrant vector database?
Qdrant is an open-source vector database written in Rust, run as a server (one Docker container to start) with HTTP and gRPC APIs and client libraries. It stores vectors with JSON payloads, supports filtering on payload fields inside the index search, offers HNSW with quantisation options, sparse vectors for hybrid search, multi-tenancy and snapshots, and has a hosted cloud version. Choose it when you have outgrown pgvector's performance or need features such as native hybrid search, when your vector workload should be separate from your main database, or when you want a dedicated engine you can still self-host.
What is Pinecone AI?
Pinecone is a fully managed, hosted vector database: you create an index through its API or console, upsert vectors with metadata, and query over HTTPS; scaling, replication and infrastructure are handled for you. It is attractive when you have no appetite for running servers and your data may live with a third party. The trade-offs are cost at scale, vendor dependency and data residency. For a student project or an early product I would use pgvector or Qdrant first; Pinecone makes sense for a team that values managed operations over control and has the budget for it.
Pick by situation
Where each one belongs.
Notebook, batch job, evaluation
FAISS. No server, fastest to start, easiest to inspect.
A product with a Postgres already
pgvector. One database, filters in SQL, transactions, backups.
Dedicated search at scale
Qdrant self-hosted for control and native hybrid search; Pinecone if you want it fully managed.
In the room
Where these systems get explained to students.


Read next
What the store sits between.
Choosing a store for real traffic?
I can size your data, test two options on your questions and recommend one with numbers.

