Self-hosted vector database requirements checklist

The evidence is a current list of who holds which API keys, roles and per-collection permissions, plus the configuration that enforces them. Auditors typically ask for the access control list as it stood on a sample date, the process for granting and removing access, and proof that default or shared credentials are gone. Qdrant documents admin and read-only API keys, JWT-based granular access with per-collection read or write permissions, and TLS for REST and gRPC, so exported configuration and key inventories are the artifacts to plan for. Weaviate documents API key, OIDC and RBAC user management, and Milvus documents authentication, TLS and role-based access control. Confirm with your assessor which samples they will draw and how often they expect the list refreshed.

Yes, Qdrant added JSON audit logging of authenticated API operations in v1.17.0, which is the kind of record an assessor can sample. The logs only help if they are shipped to storage the platform team cannot silently alter, retained for the period your policies require, and linked to the identity that made each call. Confirm which operations are captured, what fields each entry contains, and whether logs cover administrative actions as well as data reads and writes. Other engines in the comparison need their own audit configuration checked during selection, since the same questions apply regardless of product.

Auditors usually want backup schedules, retention settings, job success records, and restore test results showing that a backup was recovered into a working store and checked. For Qdrant, snapshots are the documented mechanism, so the evidence includes snapshot inventories, storage locations, and records of restores tested against a matching version. Keep the backup scope explicit: vectors, payloads, metadata, configuration and any replicas or derived indexes. Record who approved the restore test, the date, and the outcome. A backup that has never been restored is weak evidence, so plan restore tests as a recurring control.

Deletion evidence shows that a vector point, its payload and any copies were removed when a source record was erased or a contract ended. The record should link the source identifier to the vector identifiers, show the delete request and its timestamp, and confirm the removal in the live store. Snapshots and backups can still hold deleted data, so the evidence must also state how and when those copies expire or are rebuilt. Define this process before ingestion, because tracing vectors back to source documents is hard to add later. Confirm with counsel which deletion standard applies to your data.

It depends on whether the system that uses the store is a high-risk AI system under the Act, which counsel must confirm for your use case. If it is, Article 12(1) requires that high-risk AI systems technically allow automatic recording of events over their lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. The vector store is one component, so the logs that matter are those that show retrieval activity tied to the AI system, such as which collection was queried, by which identity, and when. Agree with your legal team which logs belong to the AI system and which to the database, and where each is kept.

Assessors want a dated configuration baseline, change records, and proof that the baseline was tested. Qdrant's security documentation states that self-deployed instances listen on all interfaces and have no authentication by default, so the baseline should show bound addresses, enabled authentication, TLS settings, and network rules. Keep infrastructure-as-code or configuration files under version control, with approvals for each change. Scan results, vulnerability remediation records and version history for the deployed release are also common requests. DeployOpen prepares these controls and evidence for an assessment, but independent auditors and certification bodies are the ones who assess them.

The organization owns the evidence, and an implementation partner can design the controls, configure the platform to produce the records, and document how each record is gathered. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Define the evidence list in the written scope before work starts, including who reviews it, where it is stored, and how often it is refreshed. Ongoing evidence collection can be covered by a retainer if your team wants that continuity.

The effort depends on how many data sources feed the store, how many compliance regimes apply, and how the tenancy model is set. A single internal document set with one user group is a much smaller exercise than several source systems with different retention rules and customer-isolated collections. The work covers scale and dimensions, filtering and hybrid search, authentication and RBAC, backup and restore rules, high availability, the embedding pipeline and licence terms. Each of these needs a decision with an owner, so the number of open decisions is the best early indicator of effort. Ask any partner to list the decisions and the people who must sign them off before agreeing scope.

Duration follows the same drivers as effort: source count, compliance scope, tenancy model and how quickly the internal team can answer. Teams with clear data owners and documented controls usually move faster than teams that must first establish what their documents contain or who may see them. Because each organization's sources and approvals differ, no general duration applies to every case. Ask for a timeline in the written scope that lists the dependencies, such as access to environments, data owner interviews and approval meetings, so that delays are visible early.

Three things matter most. First, named data owners who can say what each source contains, how it is classified and how long it must be kept. Second, access to the target environment, including cloud accounts, data center networks or air-gapped segments, plus the identity provider and key management services the vector store must integrate with. Third, a named approver who can accept requirements and trade-offs on behalf of the business and security teams. Without the approver, decisions on filtering, tenancy and restore objectives tend to stall. Confirm these roles with the partner before work starts.

Yes, a capable internal team can work through the checklist, especially when it has engineers who know the embedding pipeline and an owner for security and compliance. The checklist itself is a set of questions, and the answers depend on your data and controls. A partner adds value where the team lacks recent hands-on experience with the candidate engines, such as Qdrant, Milvus, Weaviate or PostgreSQL with pgvector, where the requirements touch several compliance regimes, or where the team needs an independent challenge to assumptions about authentication, restores and multi-tenancy. DeployOpen plans, implements, hardens and documents self-hosted platforms inside the client's own infrastructure, and can scope the requirements work as a fixed-scope engagement.

A quote follows from written scope. DeployOpen does not publish a price list, so the quote reflects the agreed scope, deliverables and timeline. Ask the partner to state which sources, environments, compliance regimes and tenancy models are covered, which documents will be delivered, such as the requirements record and decision log, and what is excluded. Confirm whether follow-on work such as implementation, testing or ongoing support is priced separately, and whether any retainer applies after delivery. Comparing quotes is only useful when they describe the same scope.

Engineers and security reviewers usually point to four areas. Authentication and RBAC matter because a self-deployed Qdrant instance listens on all interfaces and has no authentication configured by default, so access control must be designed before the store is exposed. Filtering and tenancy determine whether users only retrieve content they may see, which is hard to retrofit. Backup and restore rules define what must be recoverable and how deletion propagates to snapshots. Embedding pipeline integration decides how changed source records trigger re-embedding. Settling these early reduces rework in later stages.

Not always, but the requirements should record which obligations apply, because they set evidence needs. For example, the EU AI Act's Article 12(1) requires high-risk AI systems to technically allow automatic recording of events over the system's lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Whether a vector store falls within such obligations depends on the system it serves, so confirm that with legal or compliance owners. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications; independent auditors and certification bodies do that work.

Licence terms belong in the requirements because they determine what you may run, distribute and offer to users. Qdrant's open-source engine is Apache-2.0 licensed, and Milvus is Apache-2.0 licensed. Weaviate's LICENSE file places code outside its enterprise directory under BSD-3-Clause, while code in the separate enterprise directory needs a Weaviate enterprise license and enterprise features are enabled by a license key. Ask your legal team which features your design depends on and confirm them against each project's current license file and the vendor's terms before selection.