What it is
A vector store keeps embeddings and returns the nearest ones to a query. The idea is explained in What is a Vector Database?. This page is the choice between places to put them: an extension inside PostgreSQL (pgvector), a dedicated product (Pinecone, Qdrant, Weaviate, Milvus and others), or an in-process library (Chroma or FAISS in a single service). The brand does not fix a bad chunking strategy. Chunking: How to Split Documents for RAG and the embedding model decide whether the right paragraph is even in the candidate list.
Why and when it is used
Use pgvector when Postgres is already the system of record, the corpus is not huge, and you want one backup, one permission story and SQL filters beside the vector. Use a dedicated vector database when you need independent scaling, specialised filtering and hybrid search at a size where Postgres is struggling, or when the vendor's managed service is the operational path your team will actually run. Use an in-process index for prototypes, tests and small single-node tools.
Do not adopt a separate database for a few thousand chunks. Do not put production retrieval in an in-memory demo that forgets data on restart. Vector Database vs Traditional Database covers the "do I need one at all" question; this page assumes you do need nearest-neighbour search.
How it works
You store an id, a vector, and metadata (tenant, source, timestamp). A query embeds the question and asks for the nearest K ids, preferably with a metadata filter applied in the engine, not after you fetched a thousand neighbours and threw them away. Indexes (HNSW and others) trade recall for speed. You must measure recall on your data: an index that misses the right chunk is a fast wrong answer.
Updates and deletes matter if documents change. Some systems are awkward about updating a vector in place. Plan for re-embedding when you change the embedding model; vectors from two models are not comparable. Multi-tenant isolation is a filter you test with two tenants, not a promise on the marketing page.
Technologies and dependencies
An embedding API or local embedding model, the store itself, and a job that chunks and writes. What is RAG (Retrieval-Augmented Generation)? is the application pattern. Using PostgreSQL in AI Applications shows the Postgres path. Dedicated stores have their own clients and their own cloud bills. Your SQL database usually remains the source of document metadata even if vectors live elsewhere. Keep the document id stable so you can delete vectors when the source row is deleted.
How to get started
- Take a corpus you can read end to end in an afternoon.
- If you already run Postgres, add pgvector, store vectors for that corpus, and filter by a metadata column.
- Write twenty questions and score whether the correct chunk is in the top five. Change chunking before you change products.
- Note latency and index build time.
- Only if Postgres cannot meet the measured need, prototype one dedicated store with the same questions. Compare recall, not slogans.
- Automate re-index and delete. A store that only grows is a bug.
Keep the evaluation set. You will need it when a vendor changes a default index.
Cautions and trade-offs
Managed vector databases are another region your text is copied into. Read the data policy before you upload confidential corpora. In-process libraries inside a web dyno vanish or diverge when you run two copies. pgvector on an undersized Postgres can hurt the transactional workload; isolate workloads if retrieval traffic is heavy.
Vendor lock-in shows up in metadata filter syntax and in how you export vectors. Keep the source chunks in your own object storage or database so you can leave. And do not expect the store to know truth. It returns similar text. What is RAG (Retrieval-Augmented Generation)? still requires the model and your evaluation to handle "the answer is not in the corpus".