Which open-source vector database fits your private AI stack
If your embeddings and documents must stay inside your own infrastructure, the right open-source vector database depends on what you already run and how much operating surface you can support. Qdrant, Weaviate and Milvus are the three dedicated engines to weigh first, with pgvector and Chroma as simpler paths. Be aware that licenses differ: the open-source engines are not the same thing as the paid tiers. Weaviate's enterprise code sits in a separate directory under its own license, Qdrant's Hybrid Cloud and Private Cloud are sold through sales, and Milvus's managed options come from Zilliz.
Choose Qdrant for a focused Apache-2.0 engine where you want explicit access control and sharding without a large platform footprint. Choose Weaviate when you want keyword, vector and hybrid search behind one API and can accept a BSD-3-Clause core with enterprise features gated by a license key. Choose Milvus for large distributed deployments on Kubernetes, accepting more operating components such as etcd and object storage. Choose pgvector when vectors belong next to data already in PostgreSQL and you do not yet need a separate store. Choose Chroma for embedded use or prototypes, and plan a migration if the workload grows.
Before you commit, confirm with each vendor which features your edition includes, since access control, SSO and audit logging can sit in paid tiers. Ask for the license text covering the exact components you will deploy, and test your own dataset size and filter patterns against the operating effort your team can sustain.
Which vector database for which scenario
This table maps common scenarios to the vector database that fits them best and states the condition under which each fit holds. Read each row against your own data volume, existing database estate and team capacity, since the right choice usually depends on one of those conditions more than on raw features.
| Scenario | Best fit | Why |
|---|---|---|
| Existing PostgreSQL estate with modest vector volume | pgvector | If your team already runs and backs up PostgreSQL, pgvector adds vector columns without a new system to operate. It supports exact search by default plus HNSW and IVFFlat indexes, with vector indexing up to 2,000 dimensions. Confirm that your query latency and recall hold at your data size before committing. |
| Single-team RAG prototype | Chroma | Chroma's embedded API lets one team test retrieval quickly on a laptop or single server. The fit holds while the corpus stays small and no one needs fine-grained access control. Plan a migration step before the prototype becomes a shared production service. |
| Small production cluster needing filtering and per-collection permissions | Qdrant | Qdrant offers JSON payload filtering, dense, sparse and hybrid search, and JWT-based read or write permissions per collection. It needs block storage, not NFS or S3. Its distributed docs recommend at least three nodes so quorum survives a node failure, and the enterprise operator is part of Qdrant Private Cloud. |
| Hybrid keyword plus vector search with built-in RAG and reranking | Weaviate | Weaviate combines vector search, BM25 keyword filtering, hybrid search, RAG and reranking in one query interface. Its core is BSD-3-Clause, but features inside the enterprise directory need a license key. Confirm which RBAC and replication features your edition includes before you design around them. |
| Very large collections on Kubernetes with a dedicated platform team | Milvus | Milvus separates stateless proxies, coordinators and worker nodes, backed by etcd, object storage and a write-ahead log such as Woodpecker, Kafka or Pulsar. This suits teams that can operate those components. Standalone or Lite modes are simpler for smaller workloads, so size the operating burden against your actual volume. |
| Managed option on your own cloud | Qdrant Hybrid Cloud or Zilliz bring-your-own-cloud (confirm with each vendor) | Qdrant Hybrid Cloud runs managed clusters on your infrastructure, and Zilliz offers bring-your-own-cloud for Milvus. Neither is covered by a supplied fact on exact terms, so ask each vendor which components run in your account, who operates them, and how upgrades and support are split. |
How the architectures differ and why it changes operations
Qdrant, Weaviate and Milvus reach scale through three different designs, and each design shifts operating work to a different place. Qdrant runs distributed mode on Raft consensus for cluster topology and collection structure, splits each collection into shards across nodes, and keeps extra copies through a replication factor, which doubles storage at a factor of 2. The Qdrant distributed deployment docs recommend at least three nodes for production so quorum survives a node failure. The security docs are blunt about the default state: self-deployed instances listen on all network interfaces and have no authentication configured. Before any network exposure, set admin and read-only API keys and TLS, and confirm the bind address and firewall rules in your own environment.
Weaviate takes a different route. Its replication is leaderless, disabled by default, and enabled per collection with a replication factor. Consistency is tunable at query time through ONE, QUORUM and ALL. The practical consequence is that a collection without a replication factor has no redundancy at all, so check the replication setting on every collection before go-live. Choosing QUORUM or ALL trades latency and availability against consistency, and the right level depends on whether stale search results are acceptable for your application. Confirm how your team will test node loss against your own topology before relying on either setting.
Milvus separates storage from compute. Stateless proxies accept requests, a coordinator layer manages the cluster, and worker nodes do the work, with etcd holding metadata, MinIO, S3 or Azure Blob holding objects, and Woodpecker, Kafka or Pulsar acting as the write-ahead log. That means more moving parts to run and monitor, but it also means the object store and log backend become critical dependencies with their own backup and failover plans. Qdrant has a sharper storage constraint of its own: it needs block-level storage with a POSIX-compatible file system and cannot run on NFS or S3, with SSD or NVMe recommended. If your platform team standardizes on network file systems or object storage for stateful workloads, confirm the storage class with the vendor before choosing Qdrant, and test write latency on the disks you plan to use.
Capability table across the options
This table compares Qdrant, Weaviate, Milvus, pgvector and Chroma on license, release, deployment, scaling, security, search and managed options. Cells marked as to confirm are areas the supplied research does not cover, so verify them with the vendor or in a test deployment before you decide.
| Capability | Qdrant | Weaviate | Milvus | pgvector and Chroma |
|---|---|---|---|---|
| License | Apache-2.0 | BSD-3-Clause core. Code in the wl directory needs a Weaviate enterprise license, and enterprise features need a license key. | Apache-2.0, under LF AI and Data Foundation | pgvector: PostgreSQL License. Chroma: Apache-2.0 (to confirm for enterprise options). |
| Latest release in the research | v1.19.2 (October 5, 2026) | v1.40.1 (October 13, 2026) | v3.0.3 (October 14, 2026) and v2.6.25 (September 29, 2026) | pgvector 0.8.7 (October 1, 2026). Chroma: to confirm. |
| Deployment modes | Self-hosted Docker or Kubernetes, Qdrant Cloud, Hybrid Cloud and Private Cloud | Docker, Kubernetes and Weaviate Cloud | Milvus Lite (Python library), Standalone and Distributed on Kubernetes | pgvector runs inside PostgreSQL. Chroma: embedded, single-node and distributed modes, plus Chroma Cloud. |
| Sharding and replication | Sharding across nodes, replication factor, Raft for cluster state. Three nodes recommended for production. | Horizontal scaling. Leaderless replication, off by default, enabled per collection with a replication factor. | Disaggregated storage and compute with worker nodes. Replication details to confirm. | pgvector follows PostgreSQL replication. Chroma sharding to confirm. |
| Consistency model | Raft manages topology and collection structure. Confirm data consistency options for your workload. | Tunable ONE, QUORUM and ALL, set at query time. | To confirm in the architecture docs for your release. | pgvector follows PostgreSQL transaction semantics. Chroma: to confirm. |
| API keys and TLS | Admin and read-only API keys, TLS for REST and gRPC (since v1.2.0). Off by default. | API key and OIDC authentication. Anonymous access is discouraged outside development. | Authentication and TLS encryption supported. | pgvector inherits PostgreSQL authentication and TLS. Chroma: to confirm. |
| RBAC or per-collection permissions | JWT-based access with per-collection read or write permissions (since v1.9.0). | RBAC through the user management API with custom roles. | Role-based access control supported. | pgvector uses PostgreSQL roles and grants. Chroma: to confirm. |
| Audit logging | JSON audit logs of authenticated API operations (since v1.17.0). | To confirm in the authentication and operations docs. | To confirm for your edition and deployment. | pgvector relies on PostgreSQL logging. Chroma: to confirm. |
| Hybrid and BM25 search | Dense, sparse and hybrid search, with JSON payload filtering. | Vector search, BM25 keyword filtering and hybrid search in one query interface. | BM25 full-text, sparse vectors and hybrid dense plus sparse search. | pgvector: vector search only in this research. Chroma: to confirm. |
| Quantization | Built-in quantization that the README says cuts RAM use by up to 97%. | Vector compression through quantization. | Quantization and memory-mapped files supported. | pgvector and Chroma: to confirm. |
| Multi-tenancy | To confirm per collection and tenant model in your version. | Built-in multi-tenancy. | Database, collection, partition or partition key level. | pgvector: schema and role design in PostgreSQL. Chroma: to confirm. |
What the license and paid tiers actually gate
Qdrant's engine is licensed under Apache-2.0, which is an OSI-approved open-source license, and the open-source engine is free to self-host. The commercial layer sits outside the repository. Qdrant Cloud has a free single-node tier with 0.5 vCPU, 1 GB RAM and 4 GB disk, a usage-priced Standard tier with a 99.5% uptime SLA, and a Premium tier with a minimum spend that adds SSO, private VPC links and a 99.9% uptime SLA. Qdrant Hybrid Cloud runs managed clusters on your own infrastructure, and Qdrant Private Cloud is a dedicated, fully isolated enterprise deployment. Both are priced through Qdrant sales, so no list price is published.
- Free engine: The Apache-2.0 engine carries no license fee for self-hosting, but you still pay for the servers, storage and staff who run it.
- Managed tiers: Standard and Premium are cloud services with their own terms, so SSO and private networking are bought, not self-built, if you choose them.
- Hybrid and Private Cloud: These are quoted by Qdrant sales. Ask what is included, who operates the cluster and what upgrade support is covered.
- Enterprise Kubernetes operator: Offered with Qdrant Private Cloud. The community Helm chart lacks zero-downtime upgrades and automatic shard rebalancing, so confirm which of these you need before you choose a path.
- Written questions: Ask which features are gated by tier, whether SLA credits apply, and what the exit path is for data and snapshots.
Confirm every tier boundary and price in writing before you rely on it, since the commercial terms sit outside the open-source license.
Weaviate is a split license model. Source code outside the repository's wl directory is licensed under BSD-3-Clause, which is OSI-approved. Code inside wl is source-available under a separate Weaviate enterprise license and is not open source. Enterprise features are switched on with a license key, so a self-hosted deployment running only the BSD-3-Clause code is a different product from one with enterprise features activated. Weaviate Cloud is a managed service, and the README lists AWS and GCP marketplace deployments documented separately.
- BSD-3-Clause core: Applies to code outside
wl. Confirm the exact file set in the repository before you assert what you are running. - Enterprise license key: Required for features in
wl. Ask which capabilities depend on the key and what happens to a running cluster if the key lapses. - Authentication and RBAC: The authentication docs describe API key and OIDC options, and RBAC for custom roles. Ask the vendor whether any of these depend on the enterprise license.
- Managed and marketplace options: Weaviate Cloud and cloud marketplace listings are separate commercial routes with their own terms.
- Written questions: Ask for the list of features that require the enterprise license, the license key renewal terms, and whether support covers self-hosted clusters.
Treat any feature you plan to use as unverified until the vendor confirms it sits in the BSD-3-Clause portion or under a named license.
Milvus is licensed under Apache-2.0, is governed under the LF AI and Data Foundation, and has Zilliz as its primary contributor. The open-source project covers Milvus Lite, Standalone and Distributed deployments. Zilliz Cloud is the commercial route and offers fully managed Milvus through Serverless, Dedicated and bring-your-own-cloud options. Those managed options are priced and governed by Zilliz, not by the Apache-2.0 license, so the free project and the paid service are different commercial relationships.
- Apache-2.0 project: Covers the code in the Milvus repository, including authentication, TLS and role-based access control as described in its README.
- Zilliz Cloud Serverless: A usage-based managed option. Ask how usage is metered and what data residency options apply.
- Zilliz Cloud Dedicated: A managed cluster with its own service terms. Confirm the support model and upgrade responsibility.
- Bring-your-own-cloud: Zilliz operates the service inside your cloud account. Ask who holds the cloud credentials and who is responsible for incidents.
- Written questions: Ask which features differ between the open-source build and Zilliz Cloud, and whether any enterprise support tier is required for production use.
Confirm that the Apache-2.0 release you plan to run contains every feature in your requirements, because managed-only capabilities are not visible from the repository.
pgvector is a PostgreSQL extension under the PostgreSQL License, a permissive license that is OSI-approved. There is no separate enterprise edition of the extension itself. Paid value comes from the database and hosting services around it, such as managed PostgreSQL offerings from cloud providers or commercial PostgreSQL support. Whether those services include vector support, and at which versions, is a question for each provider, so confirm it rather than assume it.
- PostgreSQL License: Permissive terms with no separate commercial tier for the extension. Confirm the license text for your distribution.
- Managed PostgreSQL: Cloud providers may offer pgvector as part of a managed database. Ask for the supported pgvector version and extension update policy.
- Commercial PostgreSQL support: Support contracts cover the database engine. Ask whether they cover the extension and how extension bugs are handled.
- Release currency: The CHANGELOG shows version 0.8.7 released on October 1, 2026. Check the version your managed provider offers against that release.
- Written questions: Ask which pgvector version is supported, how index upgrades are handled and whether the provider has any restrictions on extension use.
Because pgvector has no paid edition of its own, the licensing questions concern your PostgreSQL platform rather than the extension.
Chroma is an Apache-2.0 vector and search database with an embedded API, single-node and distributed modes, and a managed offering called Chroma Cloud. The open-source project is free to self-host. Chroma Cloud is a separate commercial service with its own terms, and the distributed mode and cloud terms should be read against the current repository and vendor documentation before you commit to a deployment path. This comparison does not supply Chroma Cloud pricing or tier details, so those must come from the vendor.
- Apache-2.0 core: Covers the open-source project, which is OSI-approved. Confirm the license on the release you deploy.
- Chroma Cloud: A managed service with its own terms. Ask what it includes compared with self-hosting and how data is isolated.
- Distributed mode: Confirm in the current documentation which features are available in the open-source distributed build.
- Access control: Ask whether authentication and authorization features are in the open-source build or limited to the managed service.
- Written questions: Ask which features are reserved for Chroma Cloud, what support the open-source project receives and how the managed and self-hosted builds stay in step.
Check the current Chroma licensing and access control details directly, because managed and self-hosted features can change between releases.
What running each option takes from your team
Each vector database asks something different of the team that runs it. Some need a cluster and a consensus layer, some need an identity and access setup before they are safe to expose, and some reuse a database you already operate. The cards below name the task, the owner and the check to make before you commit.
Qdrant chart versus operator
Qdrant documents a community Helm chart and an enterprise Kubernetes operator offered as part of Qdrant Private Cloud. The Helm chart lacks zero-downtime upgrades and automatic shard rebalancing, so your platform team owns every upgrade window and any manual shard moves. If you need those features without building the procedures yourself, ask Qdrant sales whether the operator fits your cluster and what it costs. Confirm who performs rebalancing after a node change before you choose the chart.
Three nodes for quorum
Qdrant's distributed docs recommend at least three nodes in production so Raft quorum survives a node failure, and a shard count that is a multiple of the node count. A replication factor of 2 doubles storage, so the capacity you buy is roughly the data size times the factor, plus headroom. Your infrastructure team sizes the nodes and block storage, and your database owner picks the shard layout. Ask the vendor to confirm the sizing for your data volume before you order hardware.
Weaviate RBAC and OIDC setup
Self-hosted Weaviate supports API keys, OIDC and anonymous access, and anonymous access is discouraged outside development. Your identity team configures the OIDC provider and maps claims, while the platform team assigns custom roles through the user management API. Replication is off by default and is enabled per collection, so your data owner must set a replication factor and the consistency level each query uses. Check that anonymous access is disabled in the target environment before go-live.
Milvus etcd, storage and log
A distributed Milvus cluster depends on etcd for metadata, object storage such as MinIO, S3 or Azure Blob, and a write-ahead log built on Woodpecker, Kafka or Pulsar. Each dependency is a separate system with its own backups, upgrades and failure modes, usually run by a platform or storage team alongside the database team. Before you commit, confirm which log backend your team can operate and who answers for etcd health. Milvus Lite and Standalone avoid most of this, but they are not the distributed topology.
pgvector index tuning
pgvector runs inside a PostgreSQL instance your database team already backs up and patches, so there is no new cluster to operate. The tuning work is the HNSW and IVFFlat index choice, build parameters and the memory and maintenance time those indexes need as the table grows. Exact search is the default, so recall and latency trade-offs are a conscious decision your DBA must make and test. Confirm your vector dimensions fit the 2,000-dimension indexing limit before you design the schema.
Chroma embedded versus distributed
Chroma can run embedded inside an application process for development and small workloads, or as a distributed deployment for multi-user production. The move from one mode to the other changes how data is hosted, how clients connect and who owns availability, so an application team that starts embedded needs a migration plan before traffic grows. Ask the Chroma maintainers which mode they recommend for your concurrency and recovery targets, and what the migration path looks like. Plan the switch as a project, not a configuration change.
What buyers ask before hiring outside help
What drives the cost of self-hosting a vector database?
Most of the cost is labor and infrastructure, and both depend on the scope you agree in writing. Infrastructure includes compute, block storage (SSD or NVMe for Qdrant), backups and, for multi-node clusters, the extra copies that replication creates. Qdrant's distributed docs note that a replication factor of 2 doubles storage. Labor covers planning, deployment, hardening, backup testing, upgrades and documentation, and it recurs whenever you upgrade or change the cluster. Costs go up with scale, high availability requirements, the number of access and audit controls you need, and how many systems the store must integrate with. Ask any provider for a quote that separates one-time setup from recurring operations, and lists which vendor licenses or cloud subscriptions are your own cost rather than theirs.
Can our team run Qdrant or pgvector without outside help?
Often yes, if your team already operates PostgreSQL or a comparable stateful service and can own upgrades and backups. pgvector is an extension inside PostgreSQL, so it adds little new infrastructure, while Qdrant adds a separate stateful service with its own storage, security and cluster rules. Qdrant is not secure by default: its security docs state that self-deployed instances listen on all interfaces with no authentication, so the first hour of setup needs API keys, TLS and network restrictions. Confirm internally whether you have people who can run clusters, rehearse restores and read vendor release notes. Outside help is most useful for the security baseline, the first production cluster and the runbooks your on-call staff will follow.
What skills does a self-hosted vector database need from our team?
The work needs three skill sets: container and cluster operations, storage, and security engineering. For a Kubernetes deployment you need people who can manage stateful workloads, and Qdrant's community Helm chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, so confirm which path you will use. On storage, Qdrant requires block-level storage with a POSIX-compatible file system and cannot run on NFS or S3, so your storage team must agree to that before design starts. For security, you need owners for API keys or role-based access, TLS certificates, audit log retention and network policy. Milvus adds etcd and object storage to the operating surface, so list each component and who is on call for it.
How long does a vector database pilot take to set up?
No pilot duration has been supplied for this comparison, so no timeline is stated here. The length depends on how many data sources you connect, whether you need multi-node high availability, how much access control and audit logging you must document, and how much of the environment is new to your team. Ask any provider for a written scope that lists the environments, deliverables, acceptance tests and dates before work begins. For your own planning, ask your internal platform team to estimate the Kubernetes, storage and identity work separately, since those usually set the pace.
Do SSO and audit logs require a paid tier?
It depends on the product, so confirm each one against its current license and edition page. Qdrant's open-source engine includes API keys, TLS, JWT-based per-collection permissions and JSON audit logging of authenticated operations, according to its security docs. Qdrant's pricing page places SSO in its Premium cloud tier. Weaviate's core is BSD-3-Clause, but code in its enterprise directory needs a separate license and a license key, so check which features that covers. Milvus documents authentication, TLS and role-based access control in its README, but you should confirm current SSO and audit options with the project or Zilliz before you rely on them. Ask any vendor in writing which features are free to self-host and which require a contract.
How hard is it to switch vector databases later?
Switching is manageable when you keep embeddings and source documents in a format you can regenerate or export, and it gets expensive when they exist only inside one store. Qdrant documents snapshots for backup and restore, and it offers a migration tool for moving data into Qdrant, so check both pages against your version before you plan a move. Weaviate and Milvus have their own export and import paths, which you should test with a sample collection. Whatever you choose, record the embedding model, dimension count and distance metric, because a different model usually means re-embedding everything. Ask any provider to demonstrate a restore into a clean environment as part of acceptance.
When should we keep vectors in PostgreSQL instead?
Keep vectors in PostgreSQL when your corpus is modest, your team already runs PostgreSQL well and you need vectors joined with transactional data. pgvector is a PostgreSQL extension under the PostgreSQL License, and it supports exact search by default plus HNSW and IVFFlat approximate indexes, with vector columns indexable up to 2,000 dimensions. Consider a dedicated store such as Qdrant, Weaviate or Milvus when you need horizontal sharding, high query volume across many collections, built-in hybrid search or workloads that would compete with your relational database for memory and I/O. Test your own query latency and recall at expected volume before deciding, since no general threshold is supplied here.
What should we ask a consultant for in a vector database quote?
Ask for a fixed scope that names the vector store, the deployment path (single node, Kubernetes, or a vendor-supported cluster), the environments and the data sources. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask which items are included: access control and TLS configuration, backup and restore testing, monitoring, runbooks, and handover to your staff. Ask what is excluded, such as vendor licenses, GPU hardware or cloud accounts, and whether ongoing support or upgrades are priced as a separate retainer. DeployOpen does not publish a price list, so the written scope is the basis for any quote.
How to choose and pilot a vector database
This sequence turns a shortlist of Qdrant, Weaviate, Milvus, pgvector and Chroma into a tested choice, so the team knows which vendor claims hold in its own environment before any production data moves. Each step ends with a written output the next step depends on.
Define the retrieval workload
Platform and data owners write down the expected vector count, the embedding dimensions from the model you plan to use, the metadata filters that every query needs, and whether you need keyword (BM25) and dense search combined. Include growth expectations for the next planning horizon and the query patterns that run most often. Ask each shortlisted vendor to confirm how its filtering and hybrid search behave at your dimension and filter complexity. This step is done when the workload is a one-page document that engineering and security have both signed off on.
Set the license and paid-feature boundary
Legal, procurement and the platform lead list every feature the design depends on, such as RBAC, SSO, audit logging, replication tooling or the Kubernetes operator, and check which ones sit in the open-source core and which in an enterprise tier. Qdrant's Apache-2.0 engine, Weaviate's BSD-3-Clause core with enterprise code under its wl directory, and Milvus's Apache-2.0 license each need that check against the feature list, and pgvector is a PostgreSQL extension under its own license. Confirm the terms in writing with each vendor and record any feature that would need a paid license. This step produces a feature-to-license table that shows which capabilities are free and which carry a cost.
Test access control and TLS in a non-default configuration
The security engineer deploys each candidate in a test environment with the settings you would use in production, not the defaults. Qdrant's security documentation states that self-deployed instances listen on all interfaces with no authentication by default, so confirm that API keys, read-only keys, TLS on REST and gRPC, and per-collection permissions are enforced. Repeat the test for Weaviate's API key, OIDC and RBAC settings, and for Milvus's authentication, TLS and role model. Attempt unauthorized reads and writes and confirm that audit logs record them. This step is done when a documented test run shows every denied request was denied and every required log entry exists.
Load-test replication and failover on the intended storage
The platform engineer builds a cluster that matches the planned topology, including node count, replication factor and the storage type you will use in production. Qdrant's docs require block-level storage and do not support NFS or S3, and recommend at least three nodes for quorum, so test on that storage class rather than on a laptop. Load the dataset from step one, run the expected query mix, then stop a node and measure query behavior, recovery time and any data loss. Repeat for Weaviate's replication factor and consistency levels, and for Milvus's object storage and write-ahead log choice. This step is done when you have recorded latency, memory use and failover results for each candidate on the target hardware.
Write a switching plan using snapshots and export
The platform lead and data owner document how data would leave each candidate if the choice proves wrong later. Confirm that the snapshot or backup method works on the pilot data, check the restore into a second cluster, and verify that vectors, payloads and collection schema survive the round trip. Qdrant publishes snapshot and migration documentation, and the team should test whether the same export path works for the other candidates. Note any embedding model or index setting that would force a full re-embedding on migration. This step produces a tested restore record and a written exit plan, and it is done when someone other than the author can run the restore from the document.
Where the tradeoffs land for regulated teams
For regulated teams, the first tradeoff is where vector data and its embeddings live, and all three leading options can run inside your own infrastructure. Qdrant needs block-level storage with a POSIX-compatible file system and cannot run on NFS or S3-style object storage, so the disks it sits on define where the data sits. Milvus separates storage from compute and writes to etcd, MinIO, S3 or Azure Blob, which means your residency review has to cover every one of those backing services, not only the query nodes. Weaviate's self-hosted path keeps data in the instance you run. In each case, confirm with the vendor and in your own environment which components hold copies of vectors, payloads and write-ahead logs, and where backups and snapshots are written.
Access control is where the defaults matter most. The Qdrant security documentation states that self-deployed instances listen on all network interfaces and have no authentication configured by default, so network policy and API keys must be in place before any data is loaded. Qdrant's JWT-based per-collection permissions and JSON audit logging of authenticated API operations are the features to test against your own role model. Weaviate offers API key, OIDC and RBAC through its user management API, and anonymous access is discouraged outside development. Milvus documents authentication, TLS and role-based access control. Map each collection or tenant to a named owner, then test that a read-only identity cannot write and that every privileged action appears in the logs.
On audit evidence, DeployOpen can help you prepare the controls, configuration baselines and evidence an assessment will ask for, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies decide whether that evidence is sufficient for your scope. Before you commit, confirm each platform's logging and retention behavior: what the audit log records, where it is written, how long it is kept, whether it can be shipped to your SIEM, and who can alter it. Ask the vendor for the documentation covering these points, and include the answers in the scope you agree in writing.
How DeployOpen scopes vector database selection and rollout
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For vector databases, that means working from a written scope that names the candidate engines, the data and access model, and the environment the store will run in.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We confirm which candidate engine fits your licensing position, including whether enterprise features such as SSO or audit logging are needed.
- We record your embedding dimensions, document volume, filtering needs and whether storage must sit on block volumes in your own infrastructure.
- We confirm the trust boundary, meaning which applications and users will query the store and under what authentication.
How we build
- We deploy the chosen engine in your environment, with network exposure, TLS and API key or role configuration set before any data loads.
- We set replication factors, shard counts and node counts against the availability target you define, not a default.
- We test backups and snapshot restores on the running cluster, so recovery is proven before go-live.
- We run security checks on the query API and access controls, and document any findings with owners and fixes.
How we hand over
- You receive written configuration, architecture notes and the runbook for scaling, upgrades and restores.
- We document the access model, including which keys or roles map to which collections, applications and teams.
- We prepare evidence of the controls implemented, which your auditors or certification bodies can then assess.
- Handover includes a walkthrough with the platform and security staff who will operate the database day to day.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- Retainers can cover version upgrades, reviews of new releases and re-testing after changes to access or data sources.
- We can help your team plan capacity reviews as collections grow, and confirm the impact of each engine upgrade first.
