A vector database stores the numerical representations that make meaning based search possible, and answers the question of which stored items are nearest to a query. That is genuinely all it does. The engineering interest is in doing it quickly over a large collection; the enterprise interest is almost entirely in everything around it.
Organizations tend to arrive at this decision expecting it to be about performance. For most enterprise workloads it is not. It is about permissions, lifecycle and where the data sits.
What an embedding is, and is not
An embedding is a list of numbers produced by a model from a piece of content, positioned so that content with similar meaning ends up nearby. It is what allows a search for holiday entitlement to find a passage about annual leave.
Two properties are routinely misunderstood, and both have security consequences.
An embedding is derived from the text and retains a great deal about it. It is not a hash and not anonymization. Research on inversion has repeatedly shown that meaningful information can be recovered from embeddings. Treating a vector store as low sensitivity because it holds numbers is the same category of error as treating a reversible encoding as a protection.
Most systems store the text alongside the vector anyway. The passage has to be supplied to the model to answer from, so it is usually kept next to its embedding. In practice a vector store over confidential material contains that material in readable form and inherits the classification of its most sensitive source.
OWASP added LLM08:2025 Vector and Embedding Weaknesses to its Top 10 for LLM Applications for this class of problem.
The properties that actually decide the choice
Metadata filtering, and when it is applied
The single most important capability for enterprise use, and the one most likely to be described ambiguously in product material.
Every passage needs attributes travelling with it: which source it came from, which permission groups may see it, its classification, its date. Retrieval then has to be constrained by those attributes as part of the search, not after it. A store that can only filter results after computing them will return a ranked set drawn from material the asker cannot see, and the consequences of that are set out in secure RAG architecture.
Ask specifically whether filtering is applied during the search or afterward. It is a question with a real answer, and the answer varies between products and between configurations of one product.
Hybrid retrieval
Meaning based search is poor at exact identifiers: invoice numbers, part codes, surnames, statute references. Keyword search handles those and is poor at paraphrase. Systems that combine both do better than either, and this is close to standard practice rather than an advanced feature. A store that offers only vector search will need a second system beside it.
Update and deletion
The index is a copy, and copies drift. When a document is edited, removed or has its permissions tightened at source, the store has to follow. Two questions matter: how quickly a change propagates, and whether deletion is genuinely a deletion rather than a flag that hides a row while the vector remains.
Where a deletion obligation exists, that second question is not academic. It is worth establishing before selection rather than after a request arrives.
Where it runs
The store is a copy of your content, so the deployment question that applies to the model applies to it, and it can be answered differently. Sensitive material in a managed service in an unspecified region is a data residency decision made by default. The shapes and the trade are covered in on premises and cloud AI.
Operational basics
Backup and restore, encryption at rest and in transit, authentication, authorization, and an audit log of who queried what. These are ordinary requirements and they are frequently absent or immature in newer products, because the category grew quickly around a search problem rather than around enterprise data handling. NIST's SP 800-53 catalog is the reference for what a store of this sensitivity needs.
Scale, which is usually not the constraint
Vendor material emphasizes performance at very large scale. Most enterprise corpora are not very large: an organization's policies, procedures, contracts and documentation are typically in the tens or hundreds of thousands of passages, which every serious option handles comfortably. Selecting for a scale you do not have, at the cost of filtering you do need, is the common mistake in this decision.
Two decisions upstream that constrain everything after
The store is chosen late and inherits two earlier decisions that matter more than the product does.
Which embedding model. Its dimensionality determines storage size and query cost, its context limit constrains how large a passage can be, and its training determines how well it handles your domain's vocabulary. A model that performs well on general text can be noticeably weaker on specialist material, which is worth testing on your own content rather than assuming.
It also creates a dependency. A hosted embedding model means every document sent for indexing, and every query, travels to that provider. An organization that chose a self hosted language model for data boundary reasons and then indexes the same corpus through a hosted embedding service has quietly reintroduced the boundary it was avoiding. This is a common and entirely accidental gap.
How content is divided into passages. Chunking decides what a retrieved unit contains, and therefore what the model can answer from. Passages too small lose the context that makes them meaningful; too large and they dilute the match and crowd the request. Keeping structural context with each passage, so that a clause arrives with the heading that qualifies it, is one of the higher leverage choices available and is usually made once and never revisited.
Both decisions are expensive to change later, because changing either means rebuilding the index from scratch.
You may already have one
Vector search is now a feature of databases and search platforms many organizations already run, rather than only a separate category of product. Where that is the case it deserves serious consideration, for reasons that have nothing to do with the search itself.
An existing platform already has your backup regime, your access control, your monitoring, your patching and people who know how to operate it. A new component brings none of that and adds a system to the estate. The specialist products are genuinely stronger at very large scale and at some advanced indexing, and if neither applies to your corpus, the integration argument frequently outweighs the capability one.
Lifecycle, which nobody plans and everybody needs
Three things will happen to any index that runs for a year, and each is easier with a plan.
The embedding model changes. Vectors from different models are not comparable, so adopting a better one means re-embedding the entire corpus. Knowing how long a full rebuild takes, before you need one, converts an incident into a maintenance window.
The corpus grows past its original assumptions. What was assembled for one department gets pointed at three more, and chunking or filtering decisions made for the first no longer suit the rest.
Content is deleted at source. Covered above, and worth repeating because it is the one most often discovered late.
Questions worth asking a candidate
- Is metadata filtering applied during the search, or to the results afterward?
- Is the source text stored alongside the vectors, and if so under what protection?
- What is the update path, and how long until a source change is reflected?
- Does deletion remove the vector, or hide the row?
- What is encrypted, at rest and in transit, and who holds the keys?
- Is there a query audit log, and does it record the identity of the asker?
- Where does it run, and can that be constrained to a region?
- What does a full re-embedding of our corpus cost in time?
Any product worth using can answer all eight. The value of asking is less in the answers than in finding out which questions the vendor has not been asked before.
Where to go next
The mechanism this store serves is in what enterprise RAG is, and the security architecture around it in secure RAG architecture. Whether retrieval is the right technique at all is retrieval and fine tuning compared. And because the store is a copy of your content sitting in a region somebody chose, it is as much a question of AI data residency and sovereignty as one of retrieval.
LABUSA treats this as AI data architecture rather than as a product selection, because the properties above matter more than the badge on the component. Get in touch to discuss your corpus.
Sources and further reading
- OWASP GenAI Security Project, OWASP Top 10 for LLM Applications, 2025, including LLM08 Vector and Embedding Weaknesses.
- National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Revision 5.
- National Institute of Standards and Technology, AI Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024.
Every source above was opened and read on 20 August 2026. No product is named or compared on this page, deliberately: the category moves quickly and LABUSA has no product relationship to disclose.