Qdrant vs pgvector: when each one is the right choice
If your application already runs on PostgreSQL and your corpus is modest, pgvector is usually the simpler choice, because it adds vector search to a database you already back up, secure and patch. Qdrant earns its own service when you need features pgvector does not center on, such as sharded scale-out, rich payload filtering on large collections or built-in quantization to reduce memory. Both are free to self-host: Qdrant is Apache-2.0 licensed and pgvector is released under the PostgreSQL License, so the decision turns on operating cost and architecture, not license fees. Three things decide it. The first is corpus size and growth: pgvector's HNSW and IVFFlat indexes cover vector columns up to 2,000 dimensions, and its README notes that filtering runs after the index scan, with iterative index scans available when filters remove too many candidates. Test that behavior against your real filters and recall targets before committing. The second is filtering and scaling needs: if most queries combine vector similarity with heavy metadata filters, or you expect to outgrow one node, Qdrant's payload filtering, sharding and replication are designed for that path. The third is who operates the system. A team that already runs PostgreSQL backups, upgrades and access reviews gets pgvector with little new tooling, while a separate Qdrant cluster adds nodes, storage, API key or JWT access control and upgrade procedures that someone must own.
Run a short exercise before choosing. Load a representative sample of your embeddings into both systems, run the queries your application actually sends with the filters it actually uses, and measure recall and latency at the corpus size you expect in 12 to 24 months. Ask your team who will get paged when the vector store degrades and whether they already have the skills for it. Qdrant's own docs state that self-deployed instances are not secure by default, so budget time for TLS and authentication on any new service. If you cannot confirm a performance figure for your data, treat that as a test to run, not a number to assume. A sibling comparison of performance covers how to benchmark both before adding a separate service.
Which platform fits which scenario
Each row names the better fit for a common situation and the condition that decides it. Read the rows against your corpus size, how often queries filter by tenant or metadata, and who will operate the database day to day.
| Scenario | Better fit | Deciding condition |
|---|---|---|
| Single application, modest corpus, existing PostgreSQL database | pgvector | Vectors can sit beside relational data in the same database, and exact search is the default, so no second service is needed until recall or latency falls short in your own benchmark. |
| Large corpus with heavy filtering across tenants | Qdrant | pgvector applies filters after the index scan and may need iterative scans to return enough rows, while Qdrant filters payloads natively and spreads collections across shards. Benchmark both on your own filter selectivity. |
| Team with no dedicated database operators | pgvector, if PostgreSQL is already run and backed up | Adding pgvector reuses existing backup, patching and monitoring. Qdrant adds a new stateful service with its own storage, security configuration and upgrade path that someone must own. |
| Platform team already running Kubernetes | Qdrant, if the team will run a cluster | Qdrant offers a community Helm chart, but the enterprise operator is part of Qdrant Private Cloud and the Helm chart lacks zero-downtime upgrades and automatic shard rebalancing. Confirm which path fits your support model. |
| Need for sharding and replication across nodes | Qdrant | Qdrant splits collections into shards with a replication factor, and production clusters need at least three nodes for quorum. pgvector scales through PostgreSQL's own replication and partitioning, which needs separate design work. |
| Need to shrink RAM footprint for large embeddings | Qdrant | Qdrant's built-in quantization is documented to cut RAM use by up to 97%, a vendor claim to verify on your vectors. pgvector offers halfvec and HNSW indexing, but memory use grows with index size and needs measurement. |
| Vectors above 2,000 dimensions in an indexed column | Qdrant | pgvector indexes vector columns only up to 2,000 dimensions, so higher-dimension embeddings either need the halfvec type with its own limits or a different store. Confirm the index limits for your model before choosing. |
| Storage on network file systems or object storage | pgvector, inside a PostgreSQL deployment that meets its own storage needs | Qdrant requires block-level storage with a POSIX-compatible file system and cannot run on NFS or S3. Check your storage platform against Qdrant's installation requirements before committing. |
How pgvector and Qdrant are built and what that means for operations
pgvector and Qdrant solve the same retrieval problem from opposite directions. One adds vector search to a database you may already run, the other is a separate service with its own storage, clustering and security settings. The cards below cover the decisions that change your backup, upgrade and staffing work.
pgvector shares the PostgreSQL estate
pgvector is an extension, so embeddings live in the same database as your relational data. That means one backup chain, one restore point and one upgrade window for both. Check whether your team can test extension upgrades alongside PostgreSQL major versions, which ship roughly once a year and each receive five years of support. Ask whether vector indexes will make your current backup and replica sizes materially larger before you decide.
Qdrant runs as its own service
Qdrant is a standalone Rust service with its own API, storage, backups and upgrade cycle. It needs block-level storage with a POSIX-compatible file system, and it cannot run on NFS or object storage such as S3. SSD or NVMe drives are recommended. Plan a separate monitoring, backup and on-call path for it, and confirm that your platform team can provision that storage class in your environment.
Raft governs Qdrant cluster topology
In distributed mode, Qdrant uses Raft consensus to manage cluster topology and collection structure. Qdrant's own documentation recommends at least three nodes for production so quorum survives a node failure. A three-node cluster is a standing cost in servers, storage and staff time, so compare it with a single pgvector primary and its replicas before you commit. Confirm how your team will handle node replacement.
Shard and replication planning
Qdrant splits collections into shards across nodes and keeps extra copies through a replication factor. A factor of 2 doubles storage, so storage sizing must include replicas from the start. The docs recommend a shard count that is a multiple of the node count. pgvector has no equivalent sharding layer in the extension itself, so scaling beyond one primary usually means PostgreSQL partitioning or a separate design. Ask a vendor or your own benchmark team to test both at your corpus size.
Snapshots versus database backups
Qdrant provides collection snapshots as its own backup mechanism, separate from any database backup tool you already run. pgvector vectors are backed up by whatever you use for PostgreSQL, such as physical base backups or logical dumps, so restores of vectors and business records stay consistent. Decide which recovery point objective applies to embeddings. If embeddings can be regenerated from source documents, say so in your runbook, and confirm the rebuild time with your own data volume.
Security defaults differ sharply
A self-deployed Qdrant instance listens on all network interfaces and has no authentication configured by default, so it must be secured before it reaches any network. Qdrant supports API keys, TLS, JWT-based per-collection permissions and audit logging of authenticated operations. pgvector inherits PostgreSQL authentication, roles, row-level security and TLS settings that your database team likely already manages. Check whether your identity and audit tooling can cover each one without a parallel process.
Capability comparison: filtering, indexing, scaling and security
This table compares Qdrant and pgvector on the capabilities that decide whether a corpus fits inside an existing PostgreSQL estate. Read each row against your own filter patterns, corpus size and security requirements, and treat any cell marked for confirmation as an open question for the vendor documentation. The main takeaway is that pgvector's filtering and scaling depend on the PostgreSQL deployment around it, while Qdrant supplies those controls as part of its own service.
| Capability | Qdrant | pgvector |
|---|---|---|
| License and current version | Apache-2.0, Rust; v1.19.2 published October 5, 2026 | PostgreSQL License, extension; version 0.8.7 released October 1, 2026 |
| Vector types and dimension limits | Dense, sparse and hybrid vectors in one service; confirm per-collection limits in the docs | vector and halfvec up to 16,000 dimensions; indexing of vector columns up to 2,000 dimensions |
| Distance metrics | Confirm the full metric list in the vendor documentation before design | L2, inner product, cosine, L1, Hamming and Jaccard distance operators |
| Index types | Vector index built into the engine; confirm index parameters in the docs | Exact search by default, plus HNSW and IVFFlat approximate indexes |
| Filtering with approximate indexes | JSON payload filtering on vectors inside the engine's search path | Filters apply after the index scan; iterative index scans can fetch more rows when filters remove too many |
| Horizontal scaling | Sharding and replication, with Raft consensus for cluster topology; three or more nodes recommended for production | Scales with the PostgreSQL deployment (replicas, partitioning, larger instances); confirm your database team's approach |
| Quantization and memory | Built-in quantization that the README says cuts RAM usage by up to 97% | Vector size and index memory are governed by PostgreSQL; confirm quantization options for your version |
| Authentication and access control | Admin and read-only API keys, TLS, and JWT per-collection read or write permissions; off by default | Inherits PostgreSQL roles, grants and row-level security; confirm how they map to your embedding tables |
| Audit logging | JSON audit logging of authenticated API operations since v1.17.0 | Depends on PostgreSQL logging and extensions such as pgAudit; confirm the setup in your estate |
What the licenses and editions cost you to use
pgvector is released under the PostgreSQL License, a permissive license that lets you use, modify and redistribute the extension without royalties to its maintainers. The latest release in the supplied sources is version 0.8.7, published on October 1, 2026, and it installs into a PostgreSQL server you already operate. No paid pgvector edition is documented, so the extension itself carries no license fee. The money goes to the database platform around it.
- Extension license: The PostgreSQL License covers the pgvector code. Your legal team should confirm that its terms match internal policy if you bundle the extension into your own images.
- No documented paid tier: The supplied sources describe no commercial pgvector edition and no feature gate to buy. Confirm this with the maintainers before assuming it holds for future releases.
- PostgreSQL version support: pgvector supports PostgreSQL 13 and later. PostgreSQL ships a new major version about once a year with five years of support for each, so major upgrades are a recurring cost to plan for.
- Managed services priced separately: Vector support in managed PostgreSQL comes from the wider provider market. Each provider sets its own pricing for instances, storage, backups and support, so you must price those separately.
- Support contracts: Paid support comes from your PostgreSQL provider or an outside consultancy, not from a pgvector edition. Ask for the written scope, response terms and the pgvector version the provider actually runs.
Check whether your managed provider's pgvector version matches the open-source tag you tested, since provider rollouts can lag behind releases.
Qdrant is Apache-2.0 licensed and written in Rust, and its repository and pricing page describe the open-source engine as free to self-host. The latest release in the supplied sources is v1.19.2, published on October 5, 2026. Because the engine carries no license fee, your costs move to infrastructure and to the people who run the nodes, storage, upgrades and access controls.
- License terms: Apache-2.0 permits commercial use, modification and redistribution, subject to its notice and attribution conditions. Confirm those conditions with counsel before you embed the engine in a product.
- Storage requirements: Qdrant needs block-level storage with a POSIX-compatible file system and cannot run on network file systems or object storage. SSD or NVMe drives are recommended, so budget for those volumes on every node.
- Production paths: The community Helm chart lacks zero-downtime upgrades and automatic shard rebalancing, which the enterprise Kubernetes operator in Private Cloud provides. With the community chart, that upgrade and rebalancing work stays with your team.
- Hardening effort: By default, self-deployed instances listen on all network interfaces and have no authentication. Setting up API keys, TLS and JWT-based access control is one-time work, followed by ongoing key rotation.
- Recurring infrastructure: Compute, storage and backups recur every month. Production clusters are recommended to run at least three nodes so quorum survives a node failure, and a replication factor of 2 doubles storage.
Ask Qdrant which security features in your target version, such as the JSON audit logging added in v1.17.0, are available to self-hosted deployments under the open-source license.
Qdrant's paid routes are Qdrant Cloud, Qdrant Hybrid Cloud and Qdrant Private Cloud. The pricing page lists a free single-node cloud 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. Hybrid Cloud and Private Cloud are priced through Qdrant sales, so no public figure exists for them.
- Free single-node tier: It provides 0.5 vCPU, 1 GB RAM and 4 GB disk on one node. Check whether those limits fit your corpus, query load and test environment before relying on it.
- Standard tier: Billing follows usage and the tier carries a 99.5% uptime SLA. Ask for the metering units and an illustrative invoice based on your expected traffic.
- Premium tier: It requires a minimum spend and adds SSO, private VPC links and a 99.9% uptime SLA. Confirm the commitment term and what happens to the bill if usage falls below the minimum.
- Hybrid Cloud: Managed Qdrant clusters run on infrastructure you control, and the quote covers the Qdrant service only. Your compute and storage costs in that infrastructure still apply.
- Private Cloud: It is a dedicated, fully isolated enterprise deployment that includes the enterprise Kubernetes operator. Ask for upgrade scope, support hours and exit terms in writing.
Request written quotes for each option against the same corpus size, replica count and region before you compare totals.
What drives the running cost of each option
The running cost of pgvector is mostly the PostgreSQL estate it lives in. pgvector itself is released under the PostgreSQL License, so there is no license fee for the extension. The recurring cost is the database: the compute, the storage that holds vectors next to relational rows, and the people who run PostgreSQL. PostgreSQL ships a new major version about once a year, with five years of support for each, so upgrades recur on a predictable schedule. If your team already runs a high-availability PostgreSQL cluster, adding vectors usually adds storage and memory pressure rather than a new service to pay for. Confirm with your DBA whether HNSW indexes will fit in memory alongside your current workload, because the index build and the extra RAM are where the cost tends to surprise teams. The extension also needs a pgvector version that matches your PostgreSQL major version, and each PostgreSQL upgrade becomes a vector-extension test as well.
The running cost of Qdrant adds a stateful service with its own footprint. The engine needs block-level storage with a POSIX-compatible file system and cannot run on NFS or S3, so SSD or NVMe drives are the expected class, and those drives are a recurring line item on every node. Distributed mode raises the cost in two ways: at least three nodes are recommended for production so quorum survives a node failure, and the replication factor doubles storage at a factor of 2. Quantization can lower RAM use, and Qdrant's README says it can cut RAM by up to 97%, but the saving depends on your vectors and recall targets, so measure it on your own corpus. The one-time costs are the deployment build, the security hardening (the docs state that self-deployed instances listen on all interfaces with no authentication by default), and the backup design using snapshots. The recurring costs are the drives, the nodes, monitoring, upgrades and the staff time to run them. Qdrant's enterprise Kubernetes operator and zero-downtime upgrades sit in Qdrant Private Cloud, while the community Helm chart lacks those features, so ask vendors which path their quote includes.
When requesting a quote, ask for each line separately: infrastructure per environment, storage class and replication assumptions, backup and restore testing, upgrade cadence, monitoring, and support hours and response terms. For Qdrant, ask whether the quote covers Qdrant Cloud, Hybrid Cloud, Private Cloud or self-hosting, and whether Qdrant Cloud pricing applies, since that pricing is handled through sales. For pgvector, ask who owns PostgreSQL major-version upgrades and extension compatibility testing. DeployOpen prepares a fixed-scope written plan for implementation, hardening, backup, upgrade and documentation work, and support is available as a retainer, but DeployOpen does not publish prices, so the quote follows from the scope you agree in writing.
How to move vectors from pgvector to Qdrant, or back
This sequence moves embeddings, payload metadata and query behavior between a pgvector setup and Qdrant in either direction, with checks at each stage. It ends with a validated cutover and a retired index, and it shows which parts transfer unchanged and which must be built again on the target.
Inventory dimensions, metrics and filter fields
The database owner and the application lead list every table and column that holds vectors, the embedding model and its output dimension, the distance operator each query uses, and every field used in SQL WHERE clauses. Note any column above 2,000 dimensions that is queried through an index, because pgvector's approximate indexes stop at that size, and confirm the matching limits in Qdrant's documentation. Count the collections and tables, since the cost of switching grows with that number. Done when each query path owner signs off on the inventory.
Export embeddings and metadata in batches
An engineer runs a streaming export from PostgreSQL that writes vectors, source primary keys and the payload columns the application reads, in batches so the full table never loads into memory. Keep the primary key as a payload field so results can join back to relational records. Vectors are numeric arrays in both systems and transfer unchanged, but HNSW or IVFFlat indexes do not move and must be created again. Done when row counts and sampled checksums match between the export files and the source table.
Rebuild collections and payload indexes in Qdrant
The engineer creates Qdrant collections that use the vector sizes and distance metrics from the inventory, then loads the batches through the API. Create payload indexes on every filtered field before traffic arrives, and set quantization on the target if the design calls for it. Check the Qdrant migration tool's documented sources before choosing it over a custom loader, and take snapshots of the loaded collections as a restore point. Done when collection counts match the source and snapshots are stored.
Validate recall and filters on a fixed test set
The team builds a fixed set of queries and records the exact top results from pgvector, which performs exact search by default and serves as the reference. The same queries run against Qdrant, and the team compares overlap in top-k results and in filtered result sets. Because pgvector applies filters after the index scan, approximate results can miss matches, so note where iterative index scans were needed. Done when the overlap meets the threshold the owners agreed in advance and the results are documented.
Cut over reads behind a switch
The application team routes read traffic to Qdrant through a configuration flag, keeps writes flowing to both stores during the agreed overlap period, and compares live results against the old path. Joins to relational tables must now happen in the application by ID, because Qdrant does not share a database with PostgreSQL. Done when logs show no unexpected empty results, application tests pass, and the owners approve moving reads fully to Qdrant. The same steps run in reverse for a move back to pgvector, with SQL WHERE clauses replacing Qdrant payload filters.
Retire the pgvector index and columns
After the rollback window the owners agreed, the database team drops the pgvector indexes and then the vector columns, keeps a final export or backup for audit, and updates runbooks, monitoring and backup jobs that referenced them. Confirm that the PostgreSQL backup size and job scope reflect the removed data. Done when the change is recorded in change management and no service still queries the old columns.
Where implementation projects usually run long
Implementation on the pgvector side usually runs long over index choice, filtered queries and schema design. Each vector column can use exact search or an HNSW or IVFFlat approximate index, and indexing is limited to vectors of up to 2,000 dimensions, so confirm your embedding model's output size before the schema is fixed. The pgvector README notes that filtering is applied after the index is scanned, so a selective WHERE clause can return fewer rows than expected. Plan to tune iterative index scans against your real filter combinations. Vectors that share tables with transactional data also pull backups, vacuum and migrations into the vector workload, and PostgreSQL 13 and later are supported, with a new major version about once a year. Your DBA should own the upgrade path.
On the Qdrant side, the foundation work is storage and access control. Qdrant needs block-level storage with a POSIX-compatible file system, and it cannot run on NFS or S3-compatible object storage, so SSD or NVMe volumes must be provisioned before anything else. Self-deployed instances listen on all network interfaces with no authentication by default, so the team must configure admin and read-only API keys, TLS for REST and gRPC and, where needed, JWT tokens with per-collection read or write permissions before the service is reachable from any other network. JSON audit logging of authenticated operations is available from v1.17.0. Your security team should draft the role model and certificate process before the first deployment.
Cluster sizing and operator choice are the last common overruns. Qdrant's distributed mode uses Raft for topology, and the docs recommend at least three nodes so quorum survives a failure, with a shard count that is a multiple of the node count. A replication factor of 2 doubles storage, so capacity plans must include it. The community Helm chart lacks zero-downtime upgrades and automatic shard rebalancing, which are enterprise operator features offered as part of Qdrant Private Cloud. Confirm with Qdrant sales which path your organization can use. Scope, deliverables and timelines are agreed in writing with DeployOpen before work starts, and your team should supply a Kubernetes lead, a DBA and a security owner.
Questions teams ask before they choose between Qdrant and pgvector
Is pgvector enough for my corpus if I already run PostgreSQL?
It often is for a modest corpus that already lives in PostgreSQL, but the answer depends on filtering load, recall targets and how much you want vectors to share a database with transactional data. pgvector runs exact search by default, supports HNSW and IVFFlat approximate indexes, and indexes vector columns up to 2,000 dimensions, according to its README. The README also notes that with approximate indexes, filtering runs after the index scan, and iterative index scans can fetch more results when filters remove too many. If your queries are mostly simple similarity lookups with light filters, pgvector keeps one system to back up and patch. If you need heavy payload filtering, quantization or sharding across nodes, test both before committing. Ask your team to benchmark on a copy of your data.
When does Qdrant's sharding and filtering justify a separate service?
Qdrant justifies a separate service when you need horizontal scaling, rich payload filtering on vectors, or built-in quantization that reduces memory, and when a dedicated vector team can own it. Qdrant's README describes sharding and replication, JSON payload filtering, dense, sparse and hybrid search, and quantization that it says cuts RAM usage by up to 97%. That figure is the vendor's claim and depends on your data and settings, so measure it. A single PostgreSQL instance stays simpler when vectors are a side feature. A second service adds a second backup target, a second upgrade path and a second set of access controls. Weigh that overhead against the query and scale problem you actually have.
What does running Qdrant in my own cloud actually involve?
You run the service, its storage, its access controls and its upgrades, and you pay for the infrastructure and the people who operate it. Qdrant needs block-level storage with a POSIX-compatible file system, so network file systems and object storage do not work, and SSD or NVMe drives are recommended, according to its installation docs. By default, self-deployed instances listen on all interfaces with no authentication, so API keys, TLS and network policy must be configured before any production use. For multi-node clusters, the distributed deployment docs recommend at least three nodes so quorum survives a node failure. Ask for a written list of which of these items your scope covers.
Can my own staff run Qdrant without outside help?
Yes, if you have people comfortable with Linux, storage, TLS, backups and Kubernetes or Docker operations, and someone owns the upgrade calendar. The open-source engine is free to self-host under Apache-2.0. Qdrant documents three production paths: managed Qdrant Cloud, a community Helm chart, and an enterprise Kubernetes operator offered as part of Qdrant Private Cloud. The community Helm chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, so plan manual steps for those. If your team has no database operations experience, budget for training or outside support, and confirm what is included in any support contract with the vendor.
How long does a migration from pgvector to Qdrant take?
The duration depends on corpus size, embedding pipeline complexity, how many collections you move, and how much validation your retrieval quality needs, so no general figure applies. The main drivers are re-exporting vectors and payloads, rebuilding indexes, running dual reads during cutover, and comparing recall on a fixed test set. Qdrant publishes a migration tool document that you should review before scoping, and snapshots for backup and restore. Ask any implementation partner for a written plan that names each migration step, the test set used to prove retrieval quality, and the rollback path. Treat any timeline without those details as unverified.
What does DeployOpen cover if we choose Qdrant or stay on pgvector?
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. For Qdrant, that can mean sizing, securing the default-insecure configuration, setting up clustering and backups, and writing the operating runbook. For pgvector, it can mean index design, filter testing and PostgreSQL operations. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish prices, so a quote follows from the written scope.
Which compliance evidence changes between the two options?
Both options produce evidence of configuration and access control, but the records you must keep differ by platform. For Qdrant, the security docs describe admin and read-only API keys, TLS, JWT-based per-collection permissions since v1.9.0, and JSON audit logging of authenticated API operations since v1.17.0. For pgvector, access control and audit come from PostgreSQL itself, so your existing database controls and logs may already apply. Confirm with your assessor which control evidence they expect, since DeployOpen prepares evidence but does not issue audit reports or certifications.
How DeployOpen helps you choose and run the right option
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Qdrant vs pgvector, we start from your corpus size, filtering needs and the team that will operate the database, then build whichever option the written scope supports.
How we scope
- Written scope covers corpus size, growth expectations, filter patterns and recall targets you need to meet.
- We document which PostgreSQL estate, backup tooling and operations team would own pgvector or the Qdrant service.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy the chosen option in your environment, including Qdrant API key, TLS and access settings or pgvector index configuration.
- We benchmark exact and approximate search on your own embeddings before recommending a separate vector service.
- We test authentication, network exposure and access controls, then document the results for your review.
How we hand over
- You receive architecture notes, configuration records, runbooks for backup, restore and upgrades, and the chosen rationale.
- Handover includes a walkthrough with the engineers who will operate the database after the engagement ends.
- If you later move between pgvector and Qdrant, we document the data export and reindexing steps for that path.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
- Retainers can cover version upgrades for Qdrant or PostgreSQL extensions, with test runs before each change.
- Ask us to confirm which support windows, upgrade paths and license terms apply to your chosen versions before you commit.
