Most vector database evaluations are won on query latency and recall benchmarks, and the security questions that decide whether the store can hold regulated data are asked after the contract is signed. A vector store behind a retrieval-augmented generation (RAG) application or an AI agent ends up holding chunked copies of contracts, tickets, source code and customer records, reached through a small number of powerful service credentials. The market spans managed services, self-hosted open source engines, and vector extensions to databases you already run, and the right choice depends as much on tenancy, access control, deletion and logging as on speed. This vendor-neutral buyer's guide is for platform engineers, AI engineering leads and security architects writing requirements or running a proof of concept. Hardening a store you already run is covered in the Vector Database Security Guide, and query-time permission enforcement in the Permission-Aware RAG Guide.
Key takeaways
- Classify embeddings like their source data. OWASP LLM08:2025 lists embedding inversion as a risk, so a store holding embeddings of sensitive documents inherits their classification and data protection duties.
- Buy server-enforced isolation, not a filter. Ask which unit the product enforces (namespace, tenant, collection or row) and design tenancy around it; metadata filters are a relevance tool.
- Score the credential model. Most applications reach the store with one key; scoped, short-lived, rotatable credentials and identity provider integration are where products differ most on security.
- Deletion must be provable. Erasure requests and source permission changes must reach the index, replicas and backups within a defined time.
- Test with your data and your filters. Recall and latency change sharply once access-control filters and real document sizes are applied, so benchmark them together.
Define requirements
- Workloads: RAG for internal assistants, customer-facing search, agent memory, recommendation or deduplication; expected vector counts, dimensions, write rate and queries per second at peak.
- Data in scope: classifications and regulated data types (personal data, health, payment, export-controlled), and whether any corpus must stay in a named region.
- Tenancy: internal business units, external customers, or both; contractual isolation commitments you already make to customers.
- Permission model: whether source system permissions (document libraries, wikis, ticketing) must be carried into the index and enforced per query. See the Permission-Aware RAG Guide.
- Deployment model: managed service, self-hosted in your cloud or data centre, or an extension to an existing relational database.
- Identity and operations: identity provider for console users, how applications and agents will authenticate, secrets manager, SIEM, backup tooling and the team that will run it.
| Deployment model | Strengths | Trade-offs | Fits when |
|---|---|---|---|
| Managed vector service | No infrastructure to run; provider operates scaling and patching | Data leaves your environment; features and logs may depend on plan tier | Teams without database operations capacity; data allowed in a provider region |
| Self-hosted vector engine | Full control of network, keys and location | You own authentication set-up, upgrades, backups and monitoring | Strict residency or air-gapped needs; strong platform team |
| Vector extension to an existing database | Reuses mature roles, row-level security, backup and audit tooling | Scale and index tuning limits; RLS interacts with approximate search recall | Moderate scale; data already lives in that database |
Evaluation criteria
Our illustrative weighting (an NHI Mgmt Group recommendation) for a store holding sensitive enterprise data is 25% isolation and access control, 15% credentials and identity integration, 15% data protection and deletion, 10% logging, 25% performance and operations, 10% cost and exit. Adjust it to your requirements before scoring, and score from proof of concept evidence.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Tenant isolation | Server-enforced boundary per tenant (namespace, tenant, collection or row policy) with documented guarantees and simple tenant deletion | Isolation only by metadata filter the application must always add |
| Authorisation | Role-based access with read and write separated, scoped per collection or tenant, and separate admin, backup and application roles | One key with full read, write and admin rights to everything |
| Credentials | Multiple scoped keys or short-lived tokens, rotation without downtime, workload or federated authentication options, keys never shown again after creation | Static keys in configuration files only; rotation needs an outage |
| Console and admin identity | SSO with your identity provider, enforced MFA, low default role for new users, admin actions logged | Local accounts only; shared admin login |
| Network exposure | Private connectivity, IP allow-lists, TLS on every interface, authentication on by default | Public endpoint as the only option; authentication off until configured |
| Encryption and keys | Encryption at rest and in transit, customer-managed keys available where needed, documented key rotation | No statement of how keys are held or rotated |
| Deletion and lifecycle | Delete by document or source ID across all chunks, deletion reflected in indexes, replicas and backups within a stated time, retention settings | Deletes only by vector ID; backups kept indefinitely |
| Audit logging | Logs of data-plane reads and writes, admin and key events, exportable to your SIEM, with the plan tier stated | Control-plane logs only, or logs available only on request |
| Performance with filters | Recall and latency documented and demonstrated with access-control filters applied at your selectivity | Benchmarks only without filters |
| Operations and exit | Backups and restores you can test, upgrade path, full export of vectors and metadata in an open format | No bulk export; restore only by support ticket |
Where identity fits
The application or agent key is usually the most powerful credential in the RAG stack: it can read every chunk and often write to the index, which is the route for poisoning a knowledge base. Prefer products that let each application, ingestion pipeline and agent hold its own scoped credential, issued from your secrets manager or through workload identity, with read-only keys for query paths and separate write keys for ingestion. See the RAG Security Guide.
Questions to ask vendors
- Which isolation unit does the server enforce, how is a tenant deleted, and what do you guarantee about data from one tenant appearing in another tenant's results?
- Show the role model: can we issue a key that reads one collection or tenant only, and a separate key that writes only to it?
- Do you support short-lived tokens or federated workload authentication, and can keys be rotated without downtime?
- Is authentication on by default in every deployment option, including self-hosted and development images?
- How do we delete every chunk derived from one source document, and how long until it is gone from indexes, replicas and backups?
- Which audit events do you log for data-plane queries and writes, which plan tiers include them, and how are they exported?
- Where is data and backup stored, which sub-processors handle it, and can we choose the region and use our own encryption keys?
- What recall and latency do you achieve with a filter that matches one per cent of vectors, at our scale?
- How do you publish security advisories, and what is your patch timeline for critical issues in self-hosted releases?
- How do we export all vectors and metadata at contract end, and when is our data deleted?
Red flags
- Multi-tenancy described only as "add a tenant field to your filter".
- A single all-powerful key per project with no read-only or scoped option.
- Self-hosted images that start with authentication off or a published default password, with no warning in the quick start.
- No answer on deletion from backups or replicas.
- Audit logging limited to console activity, or not available for the deployment you are buying.
- Benchmarks that never apply access-control filters.
- No bulk export path.
Proof of concept
- Load a representative, de-identified sample of your corpus with your chunking and embedding model, including documents from at least two permission groups or tenants.
- Configure isolation the way production will run, then query as tenant A with every filter and method you can find and confirm no tenant B content is returned.
- Issue separate read and write credentials; confirm the read credential cannot write, delete or change configuration, then rotate both and measure downtime.
- Delete one source document and verify every derived chunk is gone from results, then ask the vendor to show the effect on replicas and backups.
- Run recall and latency tests with production-like filters at low selectivity, and compare against unfiltered results.
- Export audit logs for the test period to your SIEM and check that queries, writes, key creation and admin changes are present.
- Perform a backup and a restore to a separate environment, then export the full dataset.
- Score each candidate against the evaluation table and record the evidence behind every score.
How NHI Mgmt Group can help
We provide independent requirements and evaluation support for AI platform, RAG and NHI programmes. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Vector Database Security Guide · Permission-Aware RAG Guide · RAG Security Guide · OWASP LLM Top 10 LLM08 Vector and Embedding Weaknesses Guide · AI Platforms Guide