Which vector store fits your RAG corpus and team
If your vectors can live inside an existing PostgreSQL estate, choose pgvector. If you need a dedicated service with payload filtering, quantization and per-collection access control, choose Qdrant. If your corpus and operating team justify a disaggregated cluster on etcd, object storage and a write-ahead log, choose Milvus. All three are open source under permissive terms: pgvector ships under the PostgreSQL License, while Qdrant (Apache-2.0) and Milvus (Apache-2.0) are both Apache-2.0. Current releases at the time of writing are pgvector 0.8.7, Qdrant v1.19.2 and Milvus v3.0.3 with v2.6.25 on the second release line. The pick depends on corpus size and team, not on feature lists alone, because every option can answer a retrieval query at small scale.
Start with two questions. First, does a PostgreSQL database already run your application data, backups and access reviews? If so, pgvector keeps vectors next to relational records and adds no new service, though it runs exact search by default and needs HNSW or IVFFlat indexes for approximate search. Second, will one team own a vector service with its own backup, upgrade and access model? Qdrant runs as a single binary that you can shard and replicate across nodes, but it needs block storage on SSD or NVMe and must not sit on NFS or S3. Confirm with your platform team whether that storage class is available before you commit. Milvus is the heaviest option: its distributed mode depends on etcd, object storage and a write-ahead log, so plan for those components in your operating model.
Which platform fits which scenario
This table maps the three vector stores to common RAG situations, with the reason for each pick drawn from filtering, scaling and operating needs. Read each row as a starting point, then test the named condition against your own corpus size, access rules and on-call capacity.
| Scenario | Best fit | Why it fits and when another option wins |
|---|---|---|
| Existing PostgreSQL estate, small corpus, relational data alongside vectors | pgvector | Vectors sit in the same database as your relational data, so backups, roles and upgrades stay in one place. Exact search is the default, and HNSW or IVFFlat indexes cover vector columns up to 2,000 dimensions. Qdrant wins if filtered search latency or recall becomes the bottleneck. |
| Dedicated RAG service needing payload filtering, per-collection access control and audit logs | Qdrant | Qdrant offers JSON payload filtering, JWT-based per-collection read or write permissions since v1.9.0, and JSON audit logging since v1.17.0. pgvector applies filters after the index scan, which needs tuning. Confirm that your access model maps to Qdrant's permissions before committing. |
| Hybrid dense and sparse retrieval inside one purpose-built service | Qdrant or Milvus | Both support dense, sparse and hybrid search. Qdrant runs as a single binary, which suits a smaller team. Milvus adds BM25 full-text search and multi-tenancy at database, collection, partition or partition key level, which matters if many tenants share one cluster. |
| Very large multi-tenant corpus run by a platform team with object storage and Kubernetes skills | Milvus | Milvus separates proxies, coordinators, worker nodes, etcd, object storage and a write-ahead log, so each layer scales on its own. It also offers GPU indexing with NVIDIA CAGRA and DiskANN. Expect more components to operate, monitor and upgrade than with the other two options. |
| Small team that wants one self-hosted service without a Kubernetes platform | Qdrant | The engine runs as one Rust binary with a documented Docker and Kubernetes path. Production deployments need block storage with a POSIX file system, not NFS or S3, and at least three nodes for quorum. Milvus Standalone is simpler than Distributed, but its component set is still larger than a single Qdrant process. |
| Operations team that already runs PostgreSQL high availability and wants minimal new infrastructure | pgvector | PostgreSQL ships a major version about once a year with five years of support, so vector storage follows the same upgrade and backup policy. Vector workloads still compete with transactional load on the same database. Confirm capacity and replication design with your DBA team before loading large embeddings. |
| Corpus growing toward many nodes, where sharding and replication must be planned | Qdrant or Milvus | Qdrant splits collections into shards and keeps replicas through Raft, and replication factor 2 doubles storage. The Helm chart lacks zero-downtime upgrades and automatic shard rebalancing, which the enterprise operator provides. Milvus handles rebalancing through its distributed architecture, but its operating footprint is larger. |
| Need for a managed option with the same engine later | Qdrant or Milvus | Qdrant offers Cloud, Hybrid Cloud and Private Cloud tiers. Zilliz Cloud offers managed Milvus with Serverless, Dedicated and bring-your-own-cloud options. pgvector depends on whichever managed PostgreSQL service you use, so confirm extension support with that provider. |
What each license and edition means for self-hosting
Qdrant's engine is licensed under Apache-2.0 and the open-source engine is free to self-host, so the license itself adds no fee to a self-hosted deployment. Money enters through the vendor's commercial offerings. 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 sales.
- Engine license: Apache-2.0, so you can self-host, modify and redistribute the engine without a license fee.
- Free cloud tier: a single node with 0.5 vCPU, 1 GB RAM and 4 GB disk, suited to evaluation rather than production corpora.
- Usage and minimum-spend tiers: Standard is usage-priced, Premium carries a minimum spend and adds SSO and private VPC links.
- Enterprise self-managed paths: Hybrid Cloud and Private Cloud are quoted through sales, so ask what support, upgrades and features each includes.
- Features gated by edition: zero-downtime upgrades and automatic shard rebalancing sit with the managed or enterprise paths, while the community Helm chart lacks them.
Confirm with Qdrant which features each tier includes before you budget, because the open engine and the commercial tiers differ in operations as well as price.
pgvector is a PostgreSQL extension released under the PostgreSQL License, a permissive license with no paid edition. There is no vendor fee and no tiered feature set to buy. The cost of running it sits in the PostgreSQL estate that hosts it: database servers or cloud instances, storage, backups, high availability, patching and the staff who operate them. If your organization already runs PostgreSQL under a support contract or a managed service, pgvector adds a license-free capability to that spend rather than a new line item.
- License: PostgreSQL License, with no commercial edition of the extension itself.
- Cost driver: the PostgreSQL platform, including compute, storage, replicas and backups, which grows with the vector corpus.
- Lifecycle: PostgreSQL ships a new major version about once a year, with five years of support for each, so budget for regular major upgrades.
- Support source: if you use a managed or vendor-supported PostgreSQL, check whether pgvector versions and index types are covered by that contract.
- Version floor: the README states support for PostgreSQL 13 and later, so confirm your cluster meets it before planning.
Ask your PostgreSQL provider or DBA team which versions and extensions they support and what their upgrade cycle costs in staff time.
Milvus is licensed under Apache-2.0 and operates under the LF AI and Data Foundation, with Zilliz as its primary contributor. The open-source project can be self-hosted in its Standalone or Distributed modes without a license fee. Zilliz, the company behind it, sells Zilliz Cloud, a fully managed service offered as Serverless, Dedicated and bring-your-own-cloud options. The bring-your-own-cloud option still runs the service in your account, so the license model differs from a self-managed Distributed cluster. Pricing for the Zilliz options is set by the vendor, so request a written quote for the option you pick.
- Project license: Apache-2.0 under LF AI and Data Foundation, which governs the open-source code you run.
- Managed options: Zilliz Cloud Serverless, Dedicated and bring-your-own-cloud, each with different billing and control.
- Self-managed cost: the Distributed deployment carries no license fee but needs Kubernetes, etcd, object storage and a write-ahead log to run.
- Security features: authentication, TLS and role-based access control are part of the open project, so confirm which enterprise support terms apply to them.
- Release lines: two lines are maintained, so decide which line your support plan and upgrade policy cover.
Ask Zilliz for the exact services, support windows and data residency terms of each Zilliz Cloud option before you compare it with self-hosting.
How each architecture stores and serves vectors
The main architectural difference is where the vectors live and how many moving parts serve a query. With pgvector, vectors are a column type inside PostgreSQL, so they share the same database process, backups, roles and storage as your relational data. Search runs as ordinary SQL against an exact or approximate index (HNSW or IVFFlat). That keeps the footprint small if you already operate PostgreSQL, but it also means vector workloads compete with transactional workloads for memory, CPU and I/O. Before you commit, check the largest index you expect against the memory and disk on your existing database hosts, and confirm the PostgreSQL major version you run is supported by the PostgreSQL versioning policy.
Qdrant runs as a single service that you deploy as one binary per node. A standalone instance holds collections, payloads and vector indexes on its own storage. For growth, a distributed cluster splits each collection into shards across nodes and keeps extra copies through a replication factor, with the Raft consensus protocol managing cluster topology and collection structure. The operational consequence is that you run and monitor a separate database service, and you plan shard and replica counts up front. Qdrant also has a hard storage requirement: it needs block-level storage with a POSIX-compatible file system, SSD or NVMe is recommended, and it cannot run on network file systems such as NFS or on object storage such as S3. Confirm this with your storage team before you size a node, because a storage class that looks suitable for general workloads may not qualify.
Milvus separates the system into layers. Stateless proxies accept requests, a coordinator manages the cluster, and worker nodes handle data and query work. Metadata sits in etcd, segment data sits in object storage such as MinIO, S3 or Azure Blob, and a write-ahead log, which can be Woodpecker, Kafka or Pulsar, sits between them. Each layer can scale on its own, which suits very large corpora and teams that already run etcd, object storage and a message system. The cost is the number of components to install, secure, upgrade and back up. Milvus also offers Milvus Lite and Standalone modes for smaller use, so ask which deployment mode your target corpus and team actually need before you plan the distributed topology.
What drives the running cost of each option
Each of the three options is free to license under its open-source terms, so the running cost comes from the infrastructure beneath it, the people who operate it and any managed service you choose. The cards below separate those components so you can ask vendors and integrators for the right line items.
Infrastructure nodes and storage
Qdrant and Milvus both need compute nodes and fast block storage. Qdrant requires block-level storage with a POSIX-compatible file system and does not run on NFS or S3, and SSD or NVMe drives are recommended. pgvector adds load to the PostgreSQL servers you already pay for, which may cost nothing extra until the index outgrows them. Ask for node counts, instance sizes and disk classes for each option at your corpus size.
Replication doubles Qdrant storage
In Qdrant distributed mode, the replication factor keeps extra copies of each shard. A factor of 2 doubles storage, so a corpus that fits on one set of disks needs twice that capacity once replicated. Recurring disk cost grows with every replica you add. Ask your team to size storage with the replication factor included, not the raw vector count.
Milvus supporting services
A distributed Milvus deployment is more than worker nodes. It depends on etcd for metadata, object storage such as MinIO, S3 or Azure Blob, and a write-ahead log such as Woodpecker, Kafka or Pulsar. Each of these is a separate component to provision, pay for and keep running. Ask whether the quote covers these dependencies or only the Milvus pods.
Staff time for upgrades and backups
Software licenses are not the recurring cost that surprises teams. Upgrades, snapshot schedules, restore tests and security patching consume engineering hours on every option. pgvector shares its upgrade cycle with PostgreSQL, while a standalone Qdrant or Milvus deployment needs its own upgrade and backup routine. Ask who owns each task, how often it runs and what a restore test costs in hours.
Enterprise support and operator tiers
Some self-hosted paths carry paid tiers. The Qdrant Helm chart is community-supported and lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, which are part of the enterprise operator offered with Qdrant Private Cloud. Pricing for Hybrid and Private Cloud is set through Qdrant sales. Ask whether you need those features and get the quote in writing before you commit.
Managed services priced by usage
Managed options replace much of the infrastructure and operations line with a recurring fee. Qdrant Cloud has a free single-node tier with 0.5 vCPU, 1 GB RAM and 4 GB disk, a usage-priced Standard tier and a minimum-spend Premium tier. Zilliz Cloud offers Serverless, Dedicated and bring-your-own-cloud options. Compare the recurring fee with the staff hours and infrastructure you would otherwise carry, and ask how the bill scales with data volume.
What implementing each platform involves
The sequence below shows what a team touches first with each option, from enabling pgvector in an existing PostgreSQL database to hardening a Qdrant cluster and standing up a Milvus deployment with its supporting services. It ends with the checks that confirm each path is ready for a retrieval workload.
Confirm the PostgreSQL version and enable pgvector
Start by checking that the existing PostgreSQL server is version 13 or later, since the pgvector README states support from that version onward. A database administrator installs the pgvector extension (version 0.8.7 is the release current as of October 1, 2026, per its CHANGELOG) and enables it in the target database with CREATE EXTENSION. Done means the extension appears in the database's extension list on a non-production copy and the team has run a test query against a sample vector column. Confirm the backup and restore procedure covers the new vector data, since it lives in the same database as your relational tables.
Choose the pgvector index and filter strategy
Decide between exact search, which pgvector uses by default, and HNSW or IVFFlat approximate indexes, keeping in mind that indexed vector columns are limited to 2,000 dimensions. Filters are applied after the index scan, so queries whose filters remove many candidates may return fewer results. The database team should enable iterative index scans in strict or relaxed ordering mode for those queries and then measure recall and latency on a representative sample of your own corpus. This step is complete when the team has a written index definition and a benchmark result that shows whether filtered retrieval returns enough matches.
Deploy Qdrant and close the default exposure
Qdrant's security documentation states that a self-deployed instance listens on all network interfaces and has no authentication configured by default, so the first task is to bind it to the intended interfaces, place it behind your network controls and set authentication before any data is loaded. The platform or security engineer configures admin and read-only API keys and enables TLS for REST and gRPC. Done means an unauthenticated request to the API is rejected from every network segment except the approved ones, and this check is repeated after every configuration change.
Set JWT per-collection access and audit logging
For teams that need more than a shared key, Qdrant supports JWT-based access control with read or write permissions per collection, a capability the security documentation dates to v1.9.0. Security engineers define roles that map each application or service to the collections it may read or write, then turn on JSON audit logging of authenticated API operations, available since v1.17.0. The output is a permissions matrix that the team reviews against its data classification, plus sample log entries that show which identity made each write. Confirm the log destination and retention with your log platform owner before go-live.
Build a three-node Qdrant cluster with planned shards
Move from a single node to distributed mode only when availability or capacity requires it. Qdrant's distributed deployment documentation recommends at least three nodes so quorum survives a node failure, and a shard count that is a multiple of the node count so data spreads evenly. Set the replication factor knowing that a factor of 2 doubles storage. Self-hosted clusters handle rebalancing and resharding by hand unless you use an enterprise path, and the Helm chart lacks automatic shard rebalancing and zero-downtime upgrades. Done means a test failover of one node keeps the collection searchable and the team has a written runbook for adding nodes.
Plan Milvus deployment mode and dependencies
Milvus offers Milvus Lite as a Python library, Standalone on one machine and Distributed as a Kubernetes-native cluster. Choose the mode before provisioning anything, because the Distributed mode depends on etcd for metadata, object storage such as MinIO, S3 or Azure Blob, and a write-ahead log in Woodpecker, Kafka or Pulsar. The platform team reviews the architecture overview, picks a release line (v3.0.3 or v2.6.25 were the current releases on the Milvus releases page in October 2026), and confirms each dependency is supported, managed and backed up in your environment. Done means a written component inventory has been approved by the infrastructure and database owners.
Configure Milvus authentication, TLS and RBAC
Milvus implements authentication, TLS encryption and role-based access control, but these controls must be turned on and mapped to your teams during deployment. The security engineer enables authentication and TLS, creates roles for applications and administrators, and assigns collection or database privileges that match the data classification. Multi-tenancy at database, collection, partition or partition key level should be decided here, because it shapes the role model. Done means a test client without the correct role is denied access to a restricted collection, and the role matrix is documented for audit.
Validate operations for the team that will run it
Before choosing a path, the team should confirm it can operate what it builds. pgvector work sits with existing database administrators and needs no new service, Qdrant needs someone who can run a clustered service with Raft-based topology, and Milvus adds etcd, object storage and a log system to monitor, patch and back up. Ask for the vendor or community upgrade path for each component, test restores of snapshots or backups, and record who is on call for each service. The step closes when a restore test has been completed and the operating owner has signed off on the runbook.
What buyers ask before choosing or hiring help
How much effort does each option take to run day to day?
pgvector takes the least new effort when you already operate PostgreSQL, because it adds an extension to a database your team already backs up, monitors and upgrades. Qdrant adds one service with its own storage, API keys, TLS and upgrade cycle, but it runs as a single binary. Milvus adds the most moving parts: the architecture documentation describes stateless proxies, a coordinator and worker nodes, etcd for metadata, object storage such as MinIO, S3 or Azure Blob, and a write-ahead log. Count those dependencies, their backups and their upgrade paths before comparing licence fees, because the engineering time is usually the larger cost. Ask each vendor or partner to list every component they expect you to operate.
Is pgvector enough for my corpus size?
pgvector is often enough when vectors live beside relational data you already query, filtering needs are modest and your team is comfortable tuning PostgreSQL. The README states that vector columns can be indexed up to 2,000 dimensions with HNSW and IVFFlat, and that approximate indexes apply filters after the index scan, with iterative index scans available when filters remove too many results. Test with your own embeddings, filter selectivity and recall target before deciding. If filtered queries are central to the product, or the vector workload will compete with transactional traffic on the same database, a dedicated store deserves a serious look.
When is Qdrant cluster mode worth the operational work?
Cluster mode is worth it when one node can no longer hold the data or serve the query load within your latency and availability targets, or when you need the availability a replicated cluster gives. Qdrant distributed mode uses Raft for cluster topology, splits collections into shards and keeps copies through a replication factor, and the documentation recommends at least three nodes so quorum survives a node failure. Each extra replica also multiplies storage. Self-managed clusters also need you to plan shard counts, rebalance and reshard by hand, and the Helm chart lacks zero-downtime upgrades and automatic shard rebalancing that the enterprise operator provides. Stay on a single node until a measured need appears.
Is Milvus overkill for a small team?
For a small team with a modest corpus, Milvus is usually more platform than the problem needs. Its Standalone mode runs on a single machine and Milvus Lite runs as a Python library, so a small deployment is possible, but the Distributed mode is a Kubernetes-native cluster with several dependencies. Its strengths, including GPU indexing, DiskANN, BM25 and multi-tenancy at several levels, matter when you use them. If none of those are on your roadmap, a lighter store is easier to keep patched. Ask whether your team already runs Kubernetes, etcd and object storage in production, since that determines the real operating load.
What does a Qdrant Hybrid Cloud or Private Cloud quote depend on?
Qdrant prices Hybrid Cloud and Private Cloud through its sales team, so no public figure exists to quote here. The quote depends on the deployment model (managed clusters inside your infrastructure for Hybrid Cloud, or a dedicated isolated deployment for Private Cloud), the number of nodes and the storage and memory each needs, the support level, and whether you need the enterprise Kubernetes operator. Ask for the quote in writing with the node sizing assumptions, what is licensed versus what you run yourself, renewal terms and what the upgrade and support responsibilities are. Public free and usage-based tiers on the pricing page are a separate option and do not cover these models.
Can our own engineers run this in-house?
Your engineers can run any of the three if they have the skills the chosen option requires. A PostgreSQL team can operate pgvector with standard database practice. A team comfortable with Kubernetes and containers can run Qdrant, and the single-node setup is the simplest starting point. Milvus expects operators who can manage etcd, object storage, a write-ahead log and cluster upgrades. Honest in-house readiness depends on who will own backups, restore tests, patching, access control and on-call coverage. If those owners are not yet named, an outside implementation partner can help plan the work, but the choice of tool should still follow your team's skills.
What should we confirm with the vendor before committing?
Confirm the items that change the operating model, not only the feature list. For Qdrant, confirm the security configuration you will apply, because self-deployed instances listen on all interfaces with no authentication by default, and confirm which API key, TLS, JWT and audit logging features your version includes. For pgvector, confirm the PostgreSQL major version you run and the index types and filter behaviour for your query pattern. For Milvus, confirm the release line you will standardise on, the object store and write-ahead log you will operate, and the authentication and RBAC setup. Also confirm backup and restore procedures, upgrade paths and which features sit behind paid editions.
What does DeployOpen do for a vector database project?
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a vector store, that can mean choosing the deployment shape, configuring access control and TLS, setting up backups and restore tests, and writing the runbooks your team will use. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications.
How DeployOpen helps choose and implement a vector store
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a vector store decision, that means working from your corpus, filters, access model and operating team toward one written scope before any build starts.
How we scope
- Size the corpus, update rate and metadata filters that retrieval must honor.
- Map who runs the database: a PostgreSQL team, a platform team or a small group.
- Agree in writing which deployment path, access controls and backup targets are in scope.
How we build
- Install the chosen store inside your infrastructure with network exposure and authentication configured from the start.
- Benchmark recall and filtered query latency on your own data before committing to an index type.
- Test API keys, TLS, role permissions and audit logging against your access requirements.
How we hand over
- Document the deployment, storage layout, snapshot and restore steps and the upgrade procedure.
- Record the migration path and the cost of switching if the corpus outgrows the first choice.
- Walk your operators through runbooks so day-to-day ownership sits with your own team.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Re-run filtered retrieval tests when you upgrade the vector store or change embedding models.
- Review access, backups and version currency on a schedule agreed in the written scope.
