# Choosing Between pgvector and Dedicated Vector Databases: What the Numbers Say
## A Practical Guide for Engineering Teams
### Introduction
Many engineering teams face a common dilemma: stick with their existing PostgreSQL setup and add vector search capabilities through an extension, or invest in a standalone vector database built for one purpose. Strong opinions exist on both sides, but the conversation often lacks real numbers. This guide walks through what actual performance measurements reveal about the two approaches, so you can make an informed decision based on your workload rather than marketing claims.
—
### Understanding the Two Approaches
**pgvector** is an extension for PostgreSQL — one of the most widely used open-source relational databases. It adds native support for storing and searching vector embeddings directly inside your existing database. Your vectors live in the same tables as your other data, you query them with familiar SQL, and there’s no separate service to maintain, monitor, or keep in sync.
**Dedicated vector databases** are standalone services designed from scratch for vector search. They handle their own storage engine, indexing, and query processing independently of any other database. Popular options include Qdrant, Pinecone, Weaviate, Milvus, and ChromaDB — each with different strengths around scalability, filtering, and ease of use.
The core architectural difference is straightforward: pgvector layers vector search onto a general-purpose database, while dedicated vector databases build everything around the search workload from the ground up.
—
### How the Comparison Was Done
To get meaningful results, a side-by-side test was set up on identical hardware using 1536-dimensional vectors (matching common embedding models like OpenAI’s text-embedding-3-small). Both systems used the HNSW algorithm for approximate nearest-neighbor search, with identical index parameters, so the results would be fair and comparable.
A local test with 100,000 vectors confirmed both systems are easy to set up and work well at small scale. But real production decisions require larger data. The critical benchmark used 50 million vectors on AWS r6id.4xlarge instances (16 vCPUs, 128GB RAM) with Cohere embeddings at 768 dimensions, measuring latency at different percentiles and queries per second at controlled recall levels.
—
### What the Production-Scale Results Revealed
The numbers paint a nuanced picture — no single system dominates across every metric.
| Metric | pgvector + StreamingDiskANN | Dedicated Vector DB |
|—|—|—|
| Median latency at 99% recall | 31.07 ms | 30.75 ms |
| 95th percentile latency at 99% recall | 60.42 ms | 36.73 ms |
| 99th percentile latency at 99% recall | 74.60 ms | 38.71 ms |
| Queries per second at 99% recall | 471.57 | 41.47 |
| Median latency at 90% recall | 9.54 ms | 4.74 ms |
| Queries per second at 90% recall | 1,589.79 | 360.81 |
| Index build time (50M vectors) | 11.1 hours | 3.3 hours |
**The key takeaways:**
– **pgvector delivered roughly 11 times more throughput** than the dedicated alternative at 99% recall on 50 million vectors. Both systems stayed under 100 milliseconds at every measured percentile — well within what most applications require.
– **The dedicated database had a clear tail-latency advantage.** At the slowest end (p99), it was about 48% faster (38.71 ms vs 74.60 ms). For applications with strict latency guarantees, this matters.
– **Index building was over 3 times faster** on the dedicated system, which reduces operational friction when ingesting large batches of new data.
These results apply specifically to the pgvector setup using an additional performance extension (StreamingDiskANN), not the default pgvector configuration. That distinction is worth noting since secondary coverage of this benchmark sometimes blurs the line.
—
### When pgvector Is the Right Choice
– Your dataset is under roughly 5 to 10 million vectors, and you’re running on reasonable hardware.
– You need **transactional consistency** between your relational data and embeddings — updating a record and its vector together in a single atomic operation.
– Your team already manages PostgreSQL. Adding vector search becomes an extension and an index, not an entirely new system to deploy, monitor, back up, and troubleshoot.
– Your query concurrency is moderate — you’re not serving thousands of simultaneous vector searches per second.
### When a Dedicated Vector Database Makes Sense
– You’re working with **hundreds of millions to billions** of vectors and need distributed, horizontal scaling.
– You have **strict tail-latency requirements** where p99 response times above 25–40 milliseconds would degrade user experience.
– You need **GPU-accelerated indexing**, which points specifically to systems like Milvus.
– Your team wants **fully managed, zero-operations infrastructure** with no database tuning expertise required — cloud-native options exist for exactly this use case.
—
### FAQ
**Q: Can I just use pgvector and migrate later if I outgrow it?**
Yes. Starting with pgvector keeps you in control of your data and infrastructure with minimal upfront complexity. If your scale or latency requirements eventually demand a dedicated system, migrating is a viable path — but don’t assume you’ll need to based on projections alone.
**Q: Does pgvector support filtering alongside vector search?**
Yes. You can apply SQL WHERE clauses in the same query that performs the vector similarity search, combining relational filters with nearest-neighbor matching in one round trip.
**Q: What distance metrics does pgvector support?**
It supports L2 (Euclidean), inner product, cosine, L1 (Manhattan), and Hamming distance — covering virtually every metric used by modern embedding models.
**Q: Is the local laptop benchmark representative of production behavior?**
No. A test with 100,000 vectors on a laptop is excellent for learning and setup validation, but the real performance differences at scale only become clear with millions of vectors and concurrent query loads.
**Q: Why do the production benchmark numbers show such a large throughput gap but a smaller latency gap at the median?**
pgvector’s throughput advantage comes from its ability to handle more queries within a given time window on the same hardware. The median latency is similar because both systems efficiently handle the average query, but Qdrant’s architecture handles the worst-case queries (tail) more gracefully.
**Q: Do these results apply to all dedicated vector databases?**
No. These specific numbers compare pgvector against one particular system (Qdrant) under a specific configuration. Other vector databases like Pinecone, Weaviate, and Milvus have different performance characteristics and would produce different results.
—
### Conclusion
The data doesn’t tell a simple story of one system winning outright. pgvector and dedicated vector databases each have clear, measurable strengths. pgvector shines in throughput and operational simplicity when your vector data already lives alongside relational data. Dedicated vector databases excel when tail latency and fast index building under massive scale are the top priorities.
The right choice depends entirely on your workload’s actual requirements — not on which tool a vendor recommends or which opinion you read online. Measure your data size, your latency needs, your concurrency patterns, and your team’s operational comfort. Then let those facts guide the decision.
—
Thank you for reading
