Vector database
Last verified: June 2026· definition
A vector database (or vector index) is built to store high-dimensional embedding vectors and answer nearest-neighbor queries quickly — “find the documents whose meaning is closest to this question.”
Options range from dedicated managed services to extensions that add vector search to a database you already run, such as pgvector for Postgres. For small-to-mid corpora, an extension on your existing database is often plenty; very large or high-throughput workloads may justify a dedicated system.
The vector store is one piece of a retrieval pipeline; embedding quality, chunking, and re-ranking matter just as much for end-to-end results.
You probably already run one
Postgres with a vector extension handles a very large share of production retrieval workloads, and it comes with a decisive practical advantage: your vectors live beside the relational data you need to filter on anyway. Tenant identifiers, permissions, timestamps, and status flags are already there, so filtering during search is straightforward. A separate vector store means keeping two systems synchronised, which is real ongoing work that rarely appears in the initial comparison.
Filtering is the requirement people forget
Almost no real system can return every document to every user. Access control, tenant scoping, and date ranges all have to apply, and where filtering happens changes the results. Filtering after retrieval can return a short or empty set when the nearest matches were all inaccessible. Filtering during search avoids that but requires the metadata to be queryable alongside the vectors — which is why the filtering story matters more in this choice than raw search performance.
Approximate search is a deliberate trade
Vector indexes trade exactness for speed: they find near neighbours quickly rather than guaranteed nearest ones. That is almost always the right trade, but it is tunable, and the settings controlling it affect recall in ways that are invisible unless measured. A retrieval quality problem that resists chunking and reranking changes is occasionally an index configured for speed at the expense of recall.
Storage and index size are separate costs
Vectors are dense arrays of floating-point numbers, and at corpus scale they are substantially larger than the text they represent. On top of that, the search index itself consumes memory, often needing to be resident to deliver low-latency queries. Capacity planning that accounts only for raw vector storage tends to underestimate, and the surprise usually arrives at the point where the index no longer fits comfortably in memory and latency degrades sharply.
Keep the source text
Storing the original text alongside its vector looks redundant and repeatedly proves essential. You need it to show users what was retrieved, to pass passages to a model, to debug why a query matched, and above all to re-embed when you change models. Systems that discarded the source have to re-extract from original documents to rebuild, which turns an expensive migration into a considerably worse one.
Common misconceptions
MythYou need a dedicated vector database to do RAG.
RealityA general-purpose database with vector support covers most workloads and removes a synchronisation problem. Dedicated stores earn their place at scale or for specific features, not by default.
MythVector search returns the most relevant documents.
RealityIt returns the nearest vectors, which is similarity rather than relevance. The two diverge often enough that production systems add keyword search and reranking on top.
MythVector search is exact.
RealityProduction indexes are approximate by design, trading a small amount of recall for large speed gains. The trade is configurable and worth understanding when recall matters.
Frequently asked questions
Do I need a dedicated vector database, or is Postgres enough?
For most workloads Postgres with a vector extension is sufficient and is usually the better starting point, because it keeps vectors and relational metadata in one system. That matters more than it first appears: filtering by tenant, permission, or date during search is a hard requirement in most real applications and is far simpler when the metadata is in the same query. Move to a dedicated store when you hit a scale or feature limit you can name, rather than pre-emptively.
What happens if I change embedding models?
Every stored vector becomes invalid, because vectors from different models are not comparable and cannot be converted. You must re-embed the whole corpus and rebuild the index. This is why keeping the source text alongside the vectors matters — without it a rebuild means re-fetching or re-extracting all your original documents, which turns an expensive operation into a much worse one.
How do I handle permissions in vector search?
Store the access metadata alongside the vectors and filter during the search rather than after it. Post-filtering retrieves the nearest matches and then discards the ones the user cannot see, which can leave you with a nearly empty result set when the top matches were all restricted. Pre-filtering constrains the search space first, so the results returned are both relevant and permitted.