Definition · AI basics
Vector database
A vector database is a database built to store embeddings, the lists of numbers that represent text or images by meaning, and to find the entries nearest a query. Retrieval-augmented generation often keeps its indexed document chunks in one. Most vector databases offer approximate search, which is fast but can miss a closer match.
Last reviewed
Key points
- A vector database stores embeddings and is built to find the stored items nearest a query quickly, optionally filtered by fields such as a customer ID.
- A basic retrieval-augmented generation pipeline embeds document chunks into a vector database and fetches the nearest chunks for each question.
- Search ranks by closeness, not by who is asking. Unless the store separates users or applies their permissions, a query can return another user's data.
- OWASP's 2025 LLM Top 10 names access control gaps and leakage between users of a shared vector database as risks, and recommends permission-aware stores with strict partitioning.
How it works
A vector database holds embeddings, the vectors that stand for its stored items. A query is embedded the same way, and the database returns the stored vectors closest to it.
Comparing the query against every stored vector is too slow for a large collection. So most vector databases build an index that narrows the search to a small part of the collection. Most offer approximate nearest-neighbour search: the results are close to the query, but not guaranteed to be the closest.
In a basic retrieval-augmented generation pipeline, documents are split into chunks, each chunk is embedded and stored, and the chunks nearest each question are handed to the language model.
A query can also carry a filter on stored fields, such as a customer ID. Depending on the system, the filter runs before, during or after the vector search.
Why it matters
Closeness is the only thing a vector search ranks by. It does not know who is asking. If several customers’ documents share one store, the nearest chunk to a question may belong to someone else, and the model can repeat it.
OWASP’s 2025 LLM Top 10 lists this under LLM08, Vector and Embedding Weaknesses. Weak access controls can let the model retrieve and disclose embedded data a user should not see. Where several users or applications share one vector database, OWASP warns of “context leakage between users or queries”. Its first mitigation is permission-aware stores, with “strict logical and access partitioning” of the data.
Vendors offer that partitioning, but it is a design choice. Pinecone recommends a separate namespace per tenant, which it says “reduces the risk of application bugs that could query the wrong tenant’s data.” It offers one shared namespace with a tenant field for when isolation is not a strict requirement. Weaviate’s per-tenant isolation is disabled by default.
The stored vectors are sensitive too. The same OWASP entry warns that attackers can invert embeddings and “recover significant amounts of source information”.
Questions and answers
Do I need a separate vector database for RAG?
Not necessarily. A 2023 survey of vector database systems counts extensions that add vector search to an existing database, such as pgvector for PostgreSQL, and search engines such as Elasticsearch, alongside databases designed only for vectors.
Can one customer's data leak to another through a shared vector database?
Yes, if the store does not keep them apart. OWASP's 2025 LLM Top 10 describes one group's embeddings being retrieved for another group's queries in a shared vector database, and recommends permission-aware stores with strict partitioning between users.
Sources
- Survey of Vector Database Management SystemsJames Jie Pan, Jianguo Wang and Guoliang Li (arXiv; Tsinghua University and Purdue University), 21 Oct 2023
- Retrieval-Augmented Generation for Large Language Models: A SurveyYunfan Gao et al. (arXiv), 18 Dec 2023
- LLM08:2025 Vector and Embedding WeaknessesOWASP Gen AI Security Project
- Implement multitenancyPinecone
- Multi-tenancy operationsWeaviate