Qdrant vs pgvector: which to choose

Qdrant or pgvector: which fits your corpus and operations team

Pick pgvector when your team already runs PostgreSQL and the retrieval workload fits inside that database. Add Qdrant as a second service when you need horizontal sharding across nodes, payload filtering that stays fast at large scale, or built-in quantization to fit vectors into less RAM. For most private AI apps that start on an existing PostgreSQL estate, pgvector is the lower-effort first step, and the switch decision should be driven by measured limits rather than by assumption.

Both products are open source and self-hosted. Qdrant is Apache-2.0 licensed and pgvector is under the PostgreSQL License, so neither carries a license fee, and the comparison is about operations and fit. The costs that differ are engineering time to deploy, back up, monitor, upgrade and tune another stateful service, plus the access controls, network paths and data residency work that come with it. Those costs recur for as long as the service runs, and they land on whoever owns the platform.

Decide with three inputs. First, corpus size and growth: estimate vector count, dimensions and how fast the corpus grows, then benchmark pgvector on a copy of your data with its exact search default and its HNSW or IVFFlat indexes (pgvector supports indexing vector columns up to 2,000 dimensions, per its repository). Second, query and filter patterns: if most queries combine vector search with selective metadata filters, test those filtered queries specifically, because filter performance often decides the outcome. Third, your team: if no one can run a second database with its own backups, upgrades and failover, pgvector inside the existing estate is usually the safer choice. Confirm each limit against your own data and hardware before you commit.

Which scenario favors which platform

This table maps common situations to the platform that fits better and the condition that decides it. Read each row as a starting point, then check the condition against your own corpus size, query patterns and operations staff before committing.

Scenario	Better fit	Condition that makes it so
Small internal corpus already on PostgreSQL	pgvector	Your data already lives in PostgreSQL, search volume is modest, and the same backup, access and monitoring tooling can cover the vectors without a new service.
Large multi-tenant corpus with heavy metadata filtering	Qdrant	Many tenants and frequent filters on JSON payload fields call for a store built around payload filtering and horizontal sharding. Test filtered recall and latency on your own data before choosing.
Hybrid dense and sparse search in one query path	Qdrant	Qdrant documents dense, sparse and hybrid search natively. If you need sparse retrieval alongside dense vectors, confirm the exact query model you need against the current docs and your own tests.
Team with no database platform skills	Depends on existing skills	If nobody runs PostgreSQL today, pgvector adds little burden only when a PostgreSQL service is already supported. Otherwise Qdrant adds a separate service to learn, so confirm who will patch, back up and tune it.
Regulated environment that standardizes on PostgreSQL backups	pgvector	Existing backup, restore and retention procedures already cover PostgreSQL, so vectors inherit controls your assessors have seen. Confirm that embeddings are covered by the same classification and deletion rules.
Memory-constrained deployment needing aggressive compression	Qdrant	Qdrant's built-in quantization is designed to reduce RAM use. Measure recall after quantization on your own embeddings, since the vendor's reduction figure is not a guarantee for your workload.

How Qdrant and pgvector are built and what that means for operations

Qdrant and pgvector solve the same retrieval problem from opposite directions. One adds a dedicated service to your estate, the other adds a capability to a database you may already run, so the operational questions shift from scaling to backup, failover and tooling.

pgvector runs inside PostgreSQL

pgvector is a PostgreSQL extension under the PostgreSQL License, currently at version 0.8.7. It runs in the same process as your database, so vectors live in ordinary tables and follow the same transactions, roles and row-level policies. Exact search is the default, and HNSW or IVFFlat indexes add approximate search. Vector columns can be indexed up to 2,000 dimensions, so check that your embedding model fits that limit. Confirm index build time and memory behavior on a copy of your own corpus.

Qdrant is a dedicated Rust service

Qdrant is Apache-2.0 licensed and written in Rust, and it runs as its own service with its own storage, API and upgrade cycle. Its README describes horizontal scaling through sharding and replication, JSON payload filtering alongside vector search, and dense, sparse and hybrid search. Choose it when filtered search on large collections and horizontal growth are the main requirements. Plan for a second stateful system that needs its own monitoring, capacity planning and version tracking.

Footprint and backup responsibilities

With pgvector, vector data is backed up, restored and replicated with the rest of the PostgreSQL database, so one backup policy and one recovery runbook cover both. Qdrant needs its own snapshot and restore procedure for each collection and node, and that procedure must be tested separately. Ask your team which restore point objectives apply to embeddings, and whether embeddings can be regenerated from source documents if a restore fails. Confirm the storage and memory needs of your chosen quantization settings in your environment before sizing.

Fit with PostgreSQL tooling and high availability

pgvector inherits the tooling your DBAs already use, including streaming replication, failover managers, connection poolers, monitoring and access reviews. Its availability is only as good as that existing setup, so a vector workload can add load to a primary that is already tuned for transactions. Qdrant brings its own replication and shard placement, which means failover testing and monitoring must be designed for the new service. Confirm with your platform team which approach matches the high availability process you already audit and rehearse.

When Qdrant's filtering, sharding and quantization justify another service

Qdrant earns its own service when vector search is a load-bearing part of a product and its requirements go beyond what a PostgreSQL table can serve well. The Qdrant README describes three capabilities that matter in that case: JSON payload filtering applied to vector queries, dense, sparse and hybrid search in one system, and horizontal scaling through sharding and replication. Built-in quantization is the fourth, and the project says it cuts RAM usage by up to 97%. That figure is the project's own claim for its quantization modes, so treat it as an upper bound to test, not a number to budget against. Your corpus shape, vector dimension and recall target decide how much of it you actually get.

pgvector is a fair default for many teams, and it should be judged on its own terms first. It runs inside the PostgreSQL database you already back up, monitor and secure, so a filter such as tenant ID, document status or access group can sit in the same SQL WHERE clause as the similarity search. Version 0.8.7 supports exact search by default, HNSW and IVFFlat approximate indexes, and indexing of vector columns up to 2,000 dimensions. The need for a separate service depends on measured query load: concurrent search volume, p95 latency under your filters, index build time during ingestion and how much memory the HNSW index consumes on your hardware. Those numbers belong to your environment, not to a vendor page.

Benchmark both on your own data before deciding. Load a representative sample at full size, include the filters your users actually apply, and run the query mix at the concurrency you expect at peak. Measure recall against exact search, not just latency, because approximate indexes trade one for the other in both systems. Record the operational cost too: who patches and upgrades each service, how backups and restores are tested, and what happens to search during a PostgreSQL failover. Qdrant is licensed under Apache-2.0, which keeps the self-hosted option open, but the license does not settle the operating question. Ask your DeployOpen or internal team to write the benchmark plan against your acceptance criteria before you pick the platform.

What licensing means for each platform

Qdrant is licensed under Apache-2.0 and is written in Rust. The latest release in the supplied sources is v1.19.2, published on October 5, 2026. Apache-2.0 allows you to run, modify and redistribute the software inside your own infrastructure without a per-seat or per-query fee from the project. Your license obligations come from the notices and attribution rules in the license itself, which your legal team should review against your distribution plans.

No usage fee in the license: The license does not meter queries, vectors or users, so cost comes from compute, memory, storage and staff time.
Self-hosting is the default path: You can deploy the single binary on nodes you control, including air-gapped networks, without a separate commercial agreement.
Features are not tiered by license: Sharding, replication, payload filtering and quantization are described in the project README rather than gated behind a paid edition, which you should confirm against the current repository.
Modification rights apply: If you patch Qdrant internally, the Apache-2.0 terms govern what you must retain and disclose.

Confirm the exact license text and any attribution duties with counsel before you embed Qdrant in a product you ship to customers.

Capability comparison: Qdrant and pgvector

This table sets Qdrant, a dedicated vector database, beside pgvector, a PostgreSQL extension, across licensing, architecture, search types and indexing. Read each row as a question about your corpus and operations: where a capability is listed as a limit, that is the point where the choice usually changes. Items marked to confirm depend on your own version, configuration or workload and should be checked before you decide.

Capability	Qdrant	pgvector
License	Apache-2.0	PostgreSQL License
Language or runtime	Written in Rust, runs as its own service	C extension loaded into PostgreSQL
Where vector data lives	Separate service with its own storage	Ordinary PostgreSQL tables and columns
Horizontal scaling	Scales out through sharding and replication	Scaling depends on PostgreSQL setup; confirm your replication and partitioning approach
Sharding and replication	Documented as built in	Not part of the extension; relies on PostgreSQL features
Payload filtering	JSON payload filtering on vectors	Standard SQL WHERE filters alongside vector distance; confirm behavior with approximate indexes at your filter selectivity
Dense, sparse and hybrid search	Dense, sparse and hybrid search documented	Dense vector search; confirm sparse and hybrid patterns with your own query design
Quantization	Built-in quantization, which the README says cuts RAM usage by up to 97%	Not described in the supplied facts; confirm with the pgvector docs for your version
Exact search by default	Confirm against the Qdrant configuration for your collections	Exact search by default, with approximate indexes added on request
HNSW and IVFFlat indexes	Uses its own index structures; confirm index options for your version	HNSW and IVFFlat approximate indexes supported
Indexing dimension limit	Confirm the maximum vector size for your collection settings	Indexing of vector columns up to 2,000 dimensions (pgvector 0.8.7)

How to move from pgvector to Qdrant, or back, without losing data

This sequence moves embeddings and their payloads between pgvector and Qdrant while keeping the old index available until retrieval results match. The end state is a verified collection, a cut-over application and a retired source index, with a documented rollback path.

Inventory vectors, payloads and access rules
The team that owns the retrieval service lists every table or collection holding vectors, the embedding model and its dimension count, the metadata columns used in filters, and which users or tenants can see which rows. Pin the embedding model name and version in writing, because a change here forces re-embedding later. Done when the inventory is signed off and every filter the application uses appears on it. Confirm the dimension limit for your pgvector version, since indexing supports up to 2,000 dimensions per the pgvector 0.8.7 changelog.
Export vectors and payloads with row identifiers
Export each embedding together with its primary key, source document identifier and metadata columns, using a read-only database role so the source is not altered. Store the export in a location with the same access controls as the source table. Done when row counts in the export match the source query and a sample of exported vectors matches stored values exactly. Keep the primary key in every record, since it is the join key for later reconciliation.
Define Qdrant collections and payload schema
Create the Qdrant collection with the same vector size and distance metric as the pgvector column, and declare the payload fields that filters rely on. Decide whether quantization is enabled, and test it against recall on your own queries rather than assuming the README figure applies to your data. Done when the collection exists, its configuration is saved as code or a file under version control, and a test insert returns the expected payload. Confirm the Qdrant version you deploy against the current release listed in the Qdrant repository.
Load data and rebuild indexes
Load the exported records into Qdrant in batches, preserving the source identifier as the point key or as a payload field. Indexes for filtered fields and HNSW graphs are built by Qdrant, not copied from pgvector, so budget time for indexing and check it against your own load test. Done when point counts match the export and spot checks return the same nearest neighbours for a fixed set of queries. Re-embed only if the embedding model changed; otherwise the stored vectors transfer as they are.
Run retrieval side by side
Send the same production queries to pgvector and Qdrant in parallel and log the top results, scores and latency without showing Qdrant output to users. Compare overlap in returned identifiers, and review the mismatches with the application owner, since differences often come from approximate indexes or different filter behaviour. Done when agreed thresholds for overlap and latency are met and the differences are explained in a written review. Agree the thresholds before the test starts.
Rebuild access rules, filters and backups
Recreate tenant or role filtering in the Qdrant query layer, because row-level security in PostgreSQL does not carry over. Add backup and restore jobs for the Qdrant storage, and restore a test snapshot into a separate environment to prove it works. Done when a user without access to a document cannot retrieve it through Qdrant in an authorization test, and a restore test completes with the expected point count. Ask your security team to review these controls before cut-over.
Cut over the application and keep pgvector as fallback
Switch the application's retrieval client to Qdrant behind a configuration flag, and keep the pgvector index read-only for a defined rollback window agreed in advance. Monitor error rates and retrieval quality during the window. Done when the application serves production traffic from Qdrant with no unresolved retrieval defects. Writes made during the window must be captured in both systems or replayed, so record how that will be handled.
Retire the old index and document the move
After the rollback window closes and the owner signs off, drop the pgvector index and the embedding column that is no longer used, then keep the final export and the reconciliation report under records retention. Update the architecture record, runbooks and backup inventory. Done when the old index is removed, the record shows the cut-over date and the reconciliation results, and the on-call team has the new runbook. Reverse the order if you are moving from Qdrant back to pgvector.

Where vector database projects usually run long

The effort in either path rarely sits in the database itself. It sits in the schema and embedding pipeline around it. Whether you choose Qdrant or pgvector, you must decide how documents are chunked, which embedding model and dimension are fixed, how payload fields such as tenant, department and classification are stored, and how a re-embedding run is staged when the model changes. With pgvector, the vectors live in table columns next to the rest of your data, so the schema decision is also a relational design decision. With Qdrant, the collection, named vectors and payload indexes are a separate design that your team must version and migrate on its own. Ask for a written plan that covers the full re-embedding path, because teams that skip it often discover that ingestion and re-indexing take longer than the query tuning they planned for.

Access control is the step most often left until late. Retrieval returns text chunks, so a user who cannot open a source document must not receive its contents through a semantic search. With pgvector, you can express that rule with PostgreSQL roles, row-level security policies and views, and you can test it with the same tooling you already use for the application database. With Qdrant, filtering by tenant or group must be enforced in every query the application sends, and the API key scope and any access rules you configure must be checked against your identity model. Confirm with the vendor how each option handles API keys, roles and audit trails in your version, and write test cases that try to retrieve a chunk from outside the caller's permissions. Backup and restore deserve the same rigor. Test a full restore into a clean environment, then check that the restored index returns the same results for a fixed set of queries. Monitoring should track query latency under filters, index build time, memory use and disk growth, not only average response time.

The most common slip is assuming filtered search will be fast without measuring it. Filters that match a small share of points can change how an approximate index behaves, and the answer differs between an HNSW index in pgvector and a Qdrant collection with payload indexes. Load test with the filter combinations your users will really send, at the concurrency you expect, and include the largest tenant. Also test a re-index on a copy of production-sized data, since index builds and ingestion can dominate the schedule. Tell your implementation partner which tests are in scope, what result counts as a pass, and who signs off, so the decision between the two paths rests on measured behavior rather than on a benchmark from another workload.

What drives running cost for each option

Running cost for Qdrant and pgvector is set less by license fees, since both are open source, than by memory, the people who operate the stack and how often you patch it. Each card below names one cost driver, who carries it and what to request in a written quote.

Memory for indexes and replicas

Vector indexes are the main infrastructure cost, and they are sized by corpus volume, dimensions and index type. Qdrant's README says built-in quantization can cut RAM usage by up to 97%, which lowers the memory bill but adds a tuning step to test recall. pgvector keeps HNSW and IVFFlat indexes in the same PostgreSQL instance that serves your application data, so memory is shared with other workloads. Ask any quote to size replicas, quantization settings and the instance class for your actual vector count and dimensions.

Storage and backup scope

Storage costs grow with the vectors, payloads and index copies you keep, and with how many backups and snapshots you retain. With pgvector, vectors sit in ordinary tables, so they are included in existing PostgreSQL backup, restore and point-in-time recovery routines. With Qdrant, the vector store is a separate data set that needs its own snapshot schedule, retention and restore test. Request a quote that states which backup scope is included and who runs the restore drill.

Skills and staffing

The largest recurring cost is often people. A team that already runs PostgreSQL can usually absorb pgvector with extension upgrades, index maintenance and query tuning. Adding Qdrant introduces a second stateful service with its own monitoring, access control, failover and capacity planning, which needs staff time or an external operator. Estimate the hours per month your team can give to each system before comparing totals, and ask a provider to name the roles it covers.

Upgrades and patching cadence

Each option carries a patch and upgrade cycle that recurs for as long as the system runs. pgvector ships through the PostgreSQL extension lifecycle, and its latest release is 0.8.7, published on October 1, 2026, so each PostgreSQL upgrade needs a compatibility check for the extension. Qdrant's latest release is v1.19.2, published on October 5, 2026, and upgrades affect a separate cluster with its own test cycle. Ask for the number of upgrade windows per year in any retainer and whether breaking changes are tested before rollout.

Support and fixed-scope work

Support spend splits into one-time implementation and recurring operations. DeployOpen plans, implements, hardens, backs up and upgrades self-hosted platforms in your own infrastructure, typically under a written fixed scope, and offers ongoing support and upgrades as retainers. A fixed-scope quote usually covers initial deployment, tuning and handover, while a retainer covers patching, monitoring response and testing over time. Ask for deliverables, what is excluded, response expectations and how changes to scope are priced before work starts.

Questions teams ask before choosing Qdrant or pgvector

Is pgvector enough for our corpus size?

For many corpora already sitting in PostgreSQL, pgvector is enough, and the deciding factors are vector count, dimensions and query latency under your real load. pgvector supports exact search by default, so small collections can run without any index. For larger collections, the HNSW and IVFFlat approximate indexes are the levers, and both trade index build time, memory and recall against speed. The vector column indexing limit is 2,000 dimensions in pgvector 0.8.7, so check your embedding model's output size first. Benchmark with a copy of your data, your filters and your concurrency before deciding, because filtered queries on large tables are where extensions and dedicated engines differ most.

What does a migration from pgvector to Qdrant depend on?

The effort depends on how tightly your application couples vector search to SQL. If embeddings, metadata and business tables are joined in the same queries, moving vectors out means rewriting retrieval logic, reconciling IDs and handling consistency between two stores. If the vectors already sit in a dedicated table with a clear key, the work is mostly exporting vectors and payloads, re-indexing in Qdrant and switching the query layer. Key drivers include the number of collections, the payload schema, whether you need to keep the two stores in sync during cutover, and how much dual-running you can afford. Ask for a written inventory of queries and data flows before estimating.

Can our team run Qdrant without outside help?

A team with container, Kubernetes or VM operations experience and someone who owns backups and monitoring can usually run Qdrant, since it ships as a single Rust binary that scales by sharding and replication. The harder parts are capacity planning for RAM, choosing quantization settings and testing recovery. Teams without that experience, or without a second person for on-call, often bring in outside help for the first deployment and runbooks. DeployOpen can plan, implement, harden, back up, document and support self-hosted platforms in your own infrastructure, with scope agreed in writing before work starts, and ongoing support is available as a retainer.

How long does a pilot take and what does it need from us?

Pilot length depends on the number of data sources, how clean your embeddings are, the search patterns you must support and how quickly your security team reviews the deployment. No duration is set here, so ask for one in the written scope. From your side, expect to supply a representative data sample, the filters and query patterns that matter, access to the target cloud account or data center, named reviewers for security and data handling, and a clear success test such as recall and latency thresholds. Most engagements are fixed-scope, so a clear pilot goal shortens the discussion before work starts.

How do backups differ between pgvector and Qdrant?

With pgvector, vectors are part of the PostgreSQL database, so your existing backup, point-in-time recovery and replication processes cover them, and restores stay consistent with the rest of your data. With Qdrant, vectors and payloads live in its own storage, so you need a separate snapshot and restore procedure, a schedule, and a check that restored collections return the same results. Confirm the exact snapshot mechanics, retention and restore timing against the Qdrant documentation and your own tests. Treat a restore drill as a required test, not an assumption, for either option.

Does licensing add cost to either option?

Both are open source under permissive licenses. Qdrant is Apache-2.0 licensed and pgvector is released under the PostgreSQL License, so neither requires a license fee to self-host. The costs that remain are infrastructure, staff time, support contracts you choose to buy and any managed service fees if you change your mind. Confirm the license terms for any managed offering or add-on you consider, since those are separate products. Ask any implementation partner for a quote that lists hardware, setup, testing, documentation and retainer items separately.

How DeployOpen helps choose and implement a vector database

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the choice between Qdrant and pgvector is tested against your corpus, your filters and your team before anything is built. Engagements are fixed-scope, with the deliverables and timeline agreed in writing first.

How we scope

Written scope records corpus size, embedding dimensions, filter fields and expected query patterns for Qdrant vs pgvector
Scope names the existing PostgreSQL estate, its backup routine and who on your team will operate the chosen store
Scope states whether quantization, sharding or replication is in or out, so the quote follows from real requirements
Fixed-scope terms set deliverables and timelines in writing before work begins, and a quote follows from that scope

How we build

Deploy the candidate store in your environment with the same embedding pipeline and sample documents for a like-for-like test
Measure recall, filtered query behavior and index build time against your own data, not generic benchmarks
Configure access control, network policy and secrets handling to match your existing identity and security standards
Run security testing on the retrieval API and the data path, and record the findings with their remediation status

How we hand over

Deliver architecture notes explaining the chosen store, index type, backup approach and upgrade path for your team
Document runbooks for index maintenance, scaling triggers and restore steps, written for your operators
Provide compliance readiness evidence such as configuration records and test results, while independent auditors issue any formal assessment
Walk your operations team through the handover so they can run the service without us

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainers can cover version upgrades for Qdrant or pgvector and re-testing when your corpus grows past the scoped size
Ask any provider to confirm response times, upgrade responsibilities and who patches the underlying PostgreSQL or Qdrant hosts
Revisit the Qdrant or pgvector decision at scoped review points if filtering, scale or team skills change

Qdrant vs pgvector