pgvector is a PostgreSQL extension that adds vector similarity search to an existing relational database, and it is good enough for many RAG use cases up to roughly a few million vectors with moderate query volume; a dedicated vector database like Qdrant becomes worth the added operational complexity once the corpus grows past that range, query latency under load becomes a bottleneck, or the application needs advanced features such as multi-vector search, quantization for memory efficiency, or built-in hybrid search with sparse and dense vectors. pgvector's advantage is that it keeps vectors alongside relational data in one system, simplifying transactions, backups, and access control that already exist in Postgres; Qdrant is purpose-built for approximate nearest neighbor search and typically delivers lower and more predictable latency at scale, with native support for payload filtering and horizontal scaling across shards. A reasonable rule is to start with pgvector if Postgres is already the system of record and the dataset is modest, then migrate to Qdrant or a similar dedicated store once indexing time, query latency, or memory pressure become measurable problems in production. Nanobase AI, a Silicon Valley engineering team, benchmarks both options against real query loads before recommending a migration.
The question is rarely answered by a vector count alone
Teams often ask for a single number, "how many vectors before we need Qdrant," but the honest answer is that the trigger is usually a specific symptom, not a threshold crossed silently in the background. Three symptoms show up consistently before a migration becomes worth the effort: index rebuild time growing long enough to disrupt ingestion pipelines, query latency degrading under concurrent load even after tuning, and metadata-filtered searches losing recall because the filter and the vector search are not evaluated together efficiently.
A vector count is a proxy; the real trigger is a specific operational symptom that tuning cannot resolve.
Signals worth tracking before deciding
| Signal | What it means when it appears |
|---|---|
| HNSW index build time exceeds the ingestion window | Postgres is spending more time indexing than the pipeline can tolerate between updates |
p99 query latency degrades under concurrent load despite tuned ef_search | The single-node architecture is reaching its ceiling for the query volume |
| Filtered queries (by department, access level, or document type) return fewer relevant results than unfiltered ones | Pre-filtering and vector search are not being evaluated jointly with enough efficiency |
| Replication or backup windows grow noticeably longer | The vector data has become a significant fraction of total database size and operational load |
Watching these four signals is a better migration trigger than picking an arbitrary vector count in advance.
What actually changes operationally when moving to Qdrant
Moving from pgvector to a dedicated engine like Qdrant is not primarily about raw similarity search speed at moderate scale, since both can be fast when properly tuned. It is about the retrieval layer no longer competing with transactional workloads for the same database resources, native support for payload-based filtering that stays efficient at scale, and horizontal scaling options that pgvector, tied to a single Postgres instance's read replicas, does not offer as cleanly.
The benefit of a dedicated vector database shows up mainly under load and at scale, not in a single-query latency test.
A migration path that avoids a rewrite
- Keep documents and their metadata in the existing system of record; do not treat the vector store as the source of truth for anything but vectors and search-relevant metadata.
- Build an abstraction layer in the application code that exposes a simple
search(query, filters)interface, so the underlying store can change without touching calling code. - Re-embed and re-index the corpus into Qdrant in parallel with the existing pgvector index, rather than a cutover with no fallback.
- Run both retrieval paths against a held-out evaluation set and compare recall and latency before switching traffic.
- Cut over once the new path matches or exceeds the old one, and keep the pgvector index available briefly as a rollback option.
A parallel-run migration is slower to execute than a hard cutover but removes the risk of a silent retrieval regression going unnoticed in production.
Frequently asked questions
Can pgvector and Qdrant run side by side permanently?
Yes, some teams keep pgvector for a smaller, frequently updated collection and Qdrant for a larger, more stable corpus, splitting by access pattern rather than migrating everything to one engine.
Does migrating vector stores affect the embedding model choice?
No, the embedding model and the vector store are independent decisions; migrating the storage and indexing layer does not require re-evaluating which embedding model to use, only re-generating vectors into the new store.
Is Qdrant harder to operate than pgvector?
It requires running and monitoring a separate service rather than reusing an existing Postgres instance, which is genuine added operational surface. Qdrant's Kubernetes operator and managed options reduce this compared to a fully manual deployment.
How long does a pgvector-to-Qdrant migration typically take?
For a corpus in the low millions of chunks, re-embedding and re-indexing is often the dominant cost and can complete within days on adequate hardware; the surrounding application changes and validation typically take longer than the data migration itself.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, assesses whether a client's retrieval symptoms genuinely require a dedicated vector database or whether tuning the existing pgvector deployment resolves them first, avoiding an unnecessary migration. When a move is warranted, we run it as a parallel-validated cutover rather than a risky in-place swap. See is pgvector good enough for production for the earlier-stage version of this question, and our solutions for the full retrieval stack.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.