Vector Database Benchmarks 2026: HNSW and Quantization

TL;DR — The vector database market split into four distinct categories in 2026, and the answer to "which should I choose?" depends on your scale. pgvector is enough for RAG up to 10 million vectors; Qdrant offers the lowest p50 latency (4ms) with Rust and open-source speed leadership; Milvus is strong at scale. This piece compares pgvector, Qdrant, Milvus, and others on latency, throughput (QPS), scalability, and indexing — and, from the field, covers when to depart from the "use what you already have" principle, together with KVKK-compliant hosting.

A few years ago "vector database" was one category; now it split into at least four distinct product classes. First, the fully managed SaaS layer — no setup or operational burden, but vendor-dependent and data-outside solutions. Second, self-hosted open-source engines (Qdrant, Milvus, Weaviate OSS) — full control, but operational responsibility is yours. Third, embedded libraries you ship inside your application (Chroma, LanceDB) — lightweight and simple. Fourth, the "use what you already have" options (pgvector, Redis, OpenSearch, MongoDB Atlas).

This fragmentation both complicates and eases the choice. It complicates because there are more options; it eases because there's a suitable category for each need. Choosing the wrong category — say, deploying a heavy distributed engine for a small RAG, or using a lightweight embedded library for billions of vectors — is an expensive mistake. The right choice starts with understanding which category you're in. This piece aims to help you identify that category and the right tool within it.

"

Field observation: most teams deploy the most advanced, most scalable vector database while they still have only thousands of vectors. But for most applications "what you already have" (Postgres + pgvector) suffices. Over-engineering at an early stage means unnecessary complexity and cost.

If you already use PostgreSQL — which most applications do — pgvector is probably the right starting point. pgvector is an extension adding vector search to Postgres; you do semantic search in your existing database without deploying a separate system. This is the peak of operational simplicity: one system, one backup, one monitoring. pgvector works well up to 10 million vectors for RAG applications with moderate query volumes.

pgvector's power is in its simplicity and integration. You keep your vectors alongside your relational data; in one query you can apply both semantic similarity and relational filters (date, user, category). This eliminates the pain of syncing data between a separate vector database and a relational one. With pgvectorscale, 471 QPS at 99% recall on 50 million vectors is achievable — more than enough for many production loads. For most teams the right question isn't "which vector database" but "is pgvector not enough that I need something else?"

Where pgvector isn't enough, Qdrant is a strong option. Written in Rust, Qdrant has the lowest p50 latency among purpose-built vector databases — 4ms, p99 at 25ms. It leads on raw single-node p99 latency. On 1 million vectors (768 dimensions), it reaches roughly 1,200 QPS at 99% recall. It leads open-source speed — 10-25% faster than Weaviate or Milvus on common workloads.

Qdrant's appeal is combining performance with ease of use. You can self-host and have full control — valuable for KVKK and data sovereignty. For applications where latency is critical and low response time is needed, Qdrant is a strong pick. It also offers rich filtering and metadata support. If you need to go beyond pgvector and speed is your priority, Qdrant is usually the first open-source engine you'll evaluate. Its Rust foundation makes it both fast and resource-efficient.

At very large scale — hundreds of millions or billions of vectors — Milvus stands out. Milvus, with its distributed architecture, is designed for horizontal scaling; it's strong on throughput at scale. On p99 latency it's just behind Qdrant but leads on large-scale throughput. If you have a massive vector library and high concurrent query load, Milvus's distributed power gains value.

But Milvus's power comes with a complexity cost. Deploying and operating a distributed system is far more laborious than pgvector or single-node Qdrant. So Milvus makes sense when truly large scale is needed — deploying Milvus for a small application is over-engineering. As scale grows and single-node solutions fall short, Milvus's distributed architecture kicks in. The right question isn't "is Milvus better" but "does my scale really require Milvus?" Most teams never reach this scale; but for those who do, Milvus is a proven option.

Database	Category	Strength	When?
pgvector	Use what you have	Simplicity, integration	<10M vectors, existing Postgres
Qdrant	Open-source engine	Lowest latency (Rust)	Speed-critical, mid-large scale
Milvus	Open-source engine	Distributed scale	Hundreds of millions+ vectors
Redis	Use what you have	Fast indexing	Existing Redis, low latency

The heart of vector databases is the indexing algorithm. The most common is HNSW (Hierarchical Navigable Small World) — an approximate nearest neighbor (ANN) algorithm with a good speed-accuracy balance. HNSW offers low latency at high recall but is memory-intensive. Different databases optimize HNSW differently; and some offer alternative indexes (IVF, DiskANN).

Index selection is a tradeoff: among speed, accuracy (recall), memory, and indexing time. If you want high recall, you accept either more memory or slower queries. If memory is constrained, disk-based indexes (like DiskANN) kick in but latency rises. Understanding these tradeoffs is the basis for choosing the right database and configuration. For most applications the default HNSW suffices; but special requirements (very large scale, tight memory budget) may require evaluating alternative indexes. Indexing is the invisible but decisive layer of vector database performance.

A critical technique in large-scale vector search is quantization. Storing vectors at lower precision (int8 or less) instead of full precision (float32) dramatically reduces the memory footprint and speeds up search. In exchange there's a small accuracy loss — but for most applications this loss is negligible. Quantization is the key to hosting billions of vectors economically.

Modern vector databases offer different quantization methods: scalar quantization (simple, fast), product quantization (higher compression), and binary quantization (most aggressive). The right method depends on your scale and accuracy requirement. At small scale quantization isn't needed; but as scale grows, quantization is the indispensable tool for keeping memory cost under control. Testing quantization on your own data matters — measuring whether the accuracy loss is acceptable. This technique is an often-overlooked lever determining the economic viability of large-scale vector search.

Two fundamental metrics matter when evaluating vector database performance: latency and throughput (QPS). Latency is how long a single query takes; throughput is how many queries can be processed per second. These are different and are different priorities for different applications. An interactive application (live chat) wants low latency; a batch process (nightly indexing) wants high throughput.

Keeping this distinction in mind is essential when reading benchmark numbers. Qdrant leads on single-node p99 latency; Milvus is strong on throughput at scale. pgvectorscale reaches 471 QPS on 50 million vectors; Qdrant ~1,200 QPS on 1 million vectors; Redis reaches 15,000-40,000 vectors/sec indexing throughput. But these numbers were measured under specific conditions; your real load may differ. The right approach is benchmarking with your own data and your own query pattern — general numbers are a starting point, not a final decision.

The most critical principle in vector database selection: test with your own data. General benchmarks are measured with specific datasets, dimensions, and hardware; your real conditions may differ. Your vector dimension, data distribution, query pattern, filtering need, and hardware — all affect performance. A database may lead in a general benchmark but another may be better on your specific load.

Building your own benchmark is a few days of work but the basis for months of correct decisions. Take a sample of your real data, run your real queries, and measure latency, throughput, recall, and cost. This measurement offers a truth specific to you, independent of marketing claims and general benchmarks. The most mature teams I see ground their vector database selection in this kind of self-benchmark. Deciding with general numbers is betting on conditions someone else measured; your own benchmark is an engineering decision grounded in your reality.

In the Turkish context, a critical dimension of vector database selection is where data is hosted. Vectors are often embedded representations of sensitive documents; and those documents may contain personal data. Using a managed SaaS vector database can mean storing this data on a third party's infrastructure abroad — a problem for KVKK and sectoral regulations. In that case, a self-hosted open-source solution (pgvector, Qdrant, Milvus) is advantageous for data sovereignty.

The cost of self-hosting is the operational burden — but the return is full data control. For regulated sectors (banking, health, public sector) this control is often not negotiable but a requirement. The maturing of open-source vector databases made this self-hosting option real and strong. Running a Qdrant or Milvus on your own infrastructure provides both performance and compliance. Evaluate vector database selection not just on performance but together with your data-privacy and sovereignty requirements — especially in Turkey, the latter is often decisive.

Real-world vector search is rarely pure semantic similarity; it usually combines with filters. Constraints like "only documents this user can access," "only dated 2025," "only this category" both narrow the search and, for KVKK, block unauthorized access. But efficiently combining filtering with vector search is a technically hard problem — if the filter is too restrictive, the index is used inefficiently.

Different vector databases support filtering with different efficiency. Some apply filters efficiently during search; some apply filters post-search, which is less efficient. High-cardinality filters (highly varied metadata) and complex filter combinations strain some databases. If your application needs heavy filtering — and most enterprise applications do — include filtering performance in your selection criteria. pgvector's natural integration with relational filtering is an advantage here; Qdrant's rich filter support is strong too. Filtering is an often-overlooked but production-critical dimension of vector database selection.

The vector database is part of a RAG system; and its value is ultimately measured in retrieval quality. A database can be fast but is worthless if it returns wrong results. So vector database selection must be evaluated not just on speed and throughput but on retrieval accuracy (recall) too. Is it retrieving the right vectors, which index configuration provides the best accuracy?

Retrieval quality evaluation requires an evaluation set — queries and correct results for each. With this set, you compare different databases and index configurations on recall. Since there's a tradeoff between speed and accuracy (high recall is usually slower), evaluating these two together is essential. Looking only at speed and neglecting accuracy leads to building a fast but wrong system. Vector database selection is ultimately a RAG-quality decision; and you can only measure that quality with an evaluation set.

The healthiest approach in vector database selection is gradual scaling. Start small — for most applications pgvector or your existing infrastructure suffices. As scale grows and these solutions fall short, move to a purpose-built engine (Qdrant). At very large scale, graduate to a distributed solution (Milvus). Move to each step only when the previous is proven insufficient.

The advantage of this gradual approach is avoiding unnecessary complexity. Deploying the most scalable, most complex solution from the start is over-engineering for most teams — complexity and cost paid for a scale they'll never reach. Starting with pgvector is both simple and cheap; and switching when truly needed is far smarter than overshooting from the start. What I see: the most expensive mistake in vector database selection is deploying a system designed for billions while you still have thousands of vectors. Start small, measure, and grow only when your data shows it.

Let's reduce all this to a decision framework. If you already use Postgres and are under 10 million vectors, start with pgvector — this is right and enough for most applications. If speed is critical and you need to go beyond pgvector, evaluate Qdrant — lowest latency and open-source leadership. If you have hundreds of millions of vectors and high concurrent load, look at Milvus's distributed power. If you have existing Redis infrastructure and need fast indexing, Redis's vector capability is an option.

In all cases, benchmark with your own data — trust your reality, not general numbers. If you have KVKK requirements, prioritize self-hosted open-source solutions. Include your filtering need in the selection criteria. And measure retrieval quality with an evaluation set — speed isn't enough, accuracy is essential too. This disciplined framework turns vector database selection into an engineering decision specific to you, independent of marketing claims and following fashion. In 2026 the winning teams aren't those choosing the flashiest vector database but those choosing the tool most suited to their scale, requirements, and KVKK context, validated with their own data.

The fourth category is embedded libraries you ship inside your application — like Chroma and LanceDB. These do vector search directly within your application, without running a separate server. They're ideal for prototyping, small-scale applications, and single-machine scenarios. Setup is near-zero; you just import a library and start using it. This simplicity is very valuable for fast development.

Embedded libraries' limit is scaling. Because they run inside your application, they don't easily scale to a distributed system. But many applications never cross the single-machine limit; in that case an embedded library is a perfect way to avoid the complexity of deploying a separate server. LanceDB, with its disk-based efficient storage especially, can handle surprisingly large datasets on a single machine. In the prototype stage or at modest-scale production, embedded libraries are the often-overlooked but most practical option. Adding complexity when needed beats deploying heavy infrastructure from the start.

Vector database selection is a cost decision. Managed SaaS solutions eliminate the operational burden but bring per-use fees and vendor dependence. Self-hosted open-source solutions have zero license cost but the operational (server, maintenance, expertise) burden is on you. The balance between these depends on your scale, your team's competence, and your cost structure.

At small scale, using your existing infrastructure (pgvector) is usually most economical — no extra system, no extra cost. At large scale, the calculation gets complex: the comfort of a managed solution, or the control and potential savings of self-hosting? This decision must account not just for today's cost but for the growth projection and vendor lock-in. What I see: many teams start with a managed solution (for speed), then move to self-hosting as scale grows (for cost and control). The right cost decision looks at total cost of ownership — not just license or usage fees but all of the operational, migration, and scaling costs.

Most benchmarks measure search performance on a static dataset. But in real applications data changes constantly — new documents are added, old ones updated or deleted. In this dynamic scenario, the vector database's update performance is critical. How fast does a document become searchable when added? How efficiently is the index updated when a document is deleted?

Different databases handle update scenarios differently. Some efficiently support real-time insertion; some require periodic rebuilds of the index. If your application relies on frequently updated data — and most enterprise RAG does — include update performance in your selection criteria. Looking only at static search speed means missing the dynamic reality. Redis, with 15,000-40,000 vectors/sec indexing throughput, is strong in scenarios needing fast updates. Freshness — how fast data becomes searchable — is an important dimension of vector database selection that static benchmarks hide. In conclusion, vector database selection in 2026 is not about finding one "best" product; it's about choosing the tool most suited to your scale, requirements, and context. The market split into four categories and there's a right option for each need. Start small — for most, pgvector suffices. As scale grows, benchmarking with your own data, graduate to Qdrant for speed, Milvus for scale.

Modern retrieval requires hybrid search more than pure vector search — the combination of dense vector similarity with sparse keyword matching. In vector database selection, support for this hybrid capability is an important criterion. Some databases natively combine dense and sparse search; some offer only dense and require a separate system for sparse.

In Turkish applications hybrid search is especially valuable, because Turkish's inflection makes sparse matching (stem-based) important. If a vector database supports both semantic similarity and exact keyword matching, Turkish retrieval quality noticeably improves. So include hybrid search support in your selection criteria. A database with native hybrid support saves you the complexity of combining two separate systems. Hybrid search is 2026's retrieval standard; and choosing a vector database that supports it means being prepared for future quality needs.

Shipping a vector database to production requires not just performance but operational maturity. Monitoring capabilities, backup and recovery, high availability, and security — these are the foundations of production resilience. A database with brilliant benchmark numbers, if operationally immature, creates problems in production. An outage, a data loss, or a security gap overshadows the value of fast search.

Operational maturity is critical especially in self-hosted solutions. A managed SaaS carries most of this burden; but when you self-host, monitoring, backup, and security are your responsibility. So when deciding to self-host, ensure your team can carry this operational burden. What I see: some vector database projects stall not on performance but on operational maturity — the system is fast but not reliable. The right choice evaluates performance together with operational maturity. Production demands not just speed but reliability; and that reliability is directly tied to your chosen tool's operational maturity.

"Is pgvector really enough, or should I deploy a purpose-built engine from the start?" For most applications pgvector is more than enough up to 10 million vectors — and its integration with your existing Postgres infrastructure and operational simplicity are invaluable. Deploying a purpose-built engine from the start is usually over-engineering; stay with pgvector until you see a real performance bottleneck.

"How much should I trust benchmark numbers?" As a starting point; but not for a final decision. General benchmarks are measured under specific conditions; your data size, query pattern, and hardware may differ. A small benchmark with your own data is far more reliable than general numbers.

"Managed or self-hosted?" If you have KVKK requirements and process sensitive data, self-hosting is often necessary for data sovereignty. Otherwise, it depends on your team's capacity to carry the operational burden and your cost structure. For small teams a managed solution provides speed; at large scale self-hosting brings savings and control. The vector database is an invisible but critical foundation of your RAG system. The right choice is about finding the tool most suited to your reality, not the flashiest one. Start small, measure with your own data, grow when needed, and balance every decision with KVKK and operational maturity. Teams adopting this approach meet both today's need and tomorrow's scale — grounding it in measurement and engineering discipline, not fashion. The right vector database is not the fastest but the one most suited to your scale and context; and you can only discover that with your own data. That discovery is a few days' investment but the foundation of a correct decision that will last for months.