# Choosing a Vector Database in 2026: pgvector, Qdrant, Milvus and Weaviate Production Guide

> Source: https://sukruyusufkaya.com/en/blog/vektor-veritabani-secim-pgvector-qdrant-milvus-2026
> Updated: 2026-07-07T18:28:05.904Z
> Type: blog
> Category: yapay-zeka
**TLDR:** Scale, latency/recall tradeoff, hybrid search and hosting. Why to measure on your own data, not synthetic benchmarks, with KVKK/BDDK context.

**TL;DR —** In 2026, choosing a vector database has shifted from "which one is faster" to "which one is right for my data, my scale, my regulatory constraints." Here's a general framework: if you already run Postgres and are at a scale up to ~10M vectors, pgvector serves you more than well. If you don't run Postgres and want low latency on a single node, Qdrant, written in Rust, is a strong choice (around 4ms p50, 25ms p99). For large-scale distributed deployments and GPU acceleration, Milvus stands out. For hybrid search and GraphQL ergonomics, Weaviate shines. But my most critical warning: don't trust synthetic benchmarks; trust the **recall@k and latency SLOs on your own data.** In this piece I'll walk you through the selection criteria, the scale thresholds, the self-hosting vs. managed dilemma from a KVKK/BDDK angle, and how to set up evaluation — all from the field.

## Why this decision is harder than it looks

In my early days building RAG systems, I thought choosing a vector database was a "technical detail." I was wrong. I saw in the field that this choice directly determines a project's latency, cost, scalability, and even legal compliance. A wrong choice can force you to rewrite the entire data pipeline six months later. A right choice lets you grow the system smoothly for years.

The difficulty is this: there are more than a dozen vector databases on the market, each crushing its rivals in its own benchmark, and most of those benchmarks are run on synthetic data, under ideal conditions, tuned in the vendor's favor. My clients show me charts from marketing pages and say "this is the fastest, let's take it." I give the same answer every time: that chart wasn't measured on your data, your query patterns, your filtering needs. So it means nothing.

Let's first get to know the players, then move to the selection criteria and the real decision framework.

## Getting to know the players

The market is broad, but in practice four names come up again and again in enterprise projects: pgvector, Qdrant, Milvus, and Weaviate. Each has a personality, a strength, and an ideal use case.

**pgvector — the vector engine inside Postgres.** pgvector isn't a standalone database; it's an extension built on top of the PostgreSQL you love and trust. The implication is revolutionary: you keep your vectors in the same place as your relational data, query them with the same SQL, and use the same backup and access-control mechanisms. You don't have to manage a separate system or carry a separate operational burden. From what I've seen in the field, pgvector works extremely well at scales up to about 10 million vectors. Beyond that, especially around the 50-million-vector mark, purpose-built engines begin to pull seriously ahead.

**Qdrant — the speed beast written in Rust.** Qdrant tends to stand out with low latency on a single node. Being written in Rust gives it a serious advantage in memory safety and predictable performance. In benchmarks it's usually a leader in single-node latency; we see figures around 4ms p50 and 25ms p99. These are directional values; they vary with hardware, index configuration, and data size. But Qdrant's filtering capabilities and developer experience make it very attractive, especially for RAG.

**Milvus — the master of distributed scale.** Milvus was designed with large-scale, distributed deployments in mind. It delivers around 6ms p50 on a single node and can push these figures further down with GPU acceleration. But where Milvus truly shines is massive deployments where you need to scale to billions of vectors. If you're really working with big data on an architecture spread across multiple nodes, you'll need Milvus's distributed nature. In return you have to accept operational complexity; keeping Milvus running requires far more engineering effort than pgvector.

**Weaviate — hybrid search and GraphQL elegance.** Weaviate stands out in hybrid search (combining semantic vector search with classic keyword search) and in GraphQL-based query ergonomics. If your system requires both semantic similarity and exact matching, and your developers enjoy GraphQL's flexibility, Weaviate is a strong candidate. Hybrid search is far more important than it looks in the field; because pure vector search sometimes misses exact term matches (product codes, names, technical terms).

## Scale thresholds: 10M and 50M vectors

The practical compass I use most in the field is scale thresholds. Because as vector count grows, the equation changes fundamentally.

**Up to 10 million vectors.** In this zone you can trust pgvector. If you already have Postgres infrastructure, the operational burden of standing up a separate system often isn't worth the extra performance. pgvector's HNSW index gives quite good recall and latency at this scale. Most enterprise RAG projects in this zone (a company's internal docs, a product catalog, a knowledge base) run smoothly with pgvector.

**50 million vectors and beyond.** Here the picture changes. At this scale, purpose-built engines pull seriously ahead. In some published figures, at a 99% recall target Qdrant is reported to deliver around 41 QPS, while pgvectorscale (a performance-focused extension of pgvector) reaches around 471 QPS. Treat these figures not as hard fact but as directional; they change dramatically with hardware, version, index configuration, and recall target. But the trend they show is real: when high recall and large scale come together, the differences between index design and engine architecture turn into large performance chasms.

The real lesson here: even these figures are proof of how carefully you must read. Even within the same ecosystem (pgvector vs pgvectorscale) there are big differences. The figure a vendor shows you probably comes from a configuration tuned in their favor. Don't fully trust any figure without measuring at your own scale, at your own recall target.

## Selection criteria: what I decide on

The checklist in my head when choosing a vector database with a client is this. I evaluate each in turn:

**Scale.** How many vectors? Today and two years from now? If you're under 10M and growth is slow, pgvector is probably enough. If you're aiming for hundreds of millions, consider from the start a distributed solution like Milvus or a clustered Qdrant deployment.

**Latency / recall tradeoff.** These two are the two pans of a scale. Increasing recall (raising the rate of not missing correct results) usually increases latency. Which is critical for your application? In a real-time recommendation system, latency is sacred; in a legal document search, recall is sacred. Define this balance from the start.

**Hybrid search.** Do you need keyword / exact-term matching alongside semantic search? If product codes, names, and technical terms are involved, probably yes. Then Weaviate or engines that support hybrid search well come to the fore.

**Filtering.** Do you need to filter the vector search by metadata? "Only documents after 2025," "only belonging to this department," "only accessible by this user." Filtering performance varies significantly across engines and is almost always required in RAG. Qdrant is strong here.

**Managed or self-hosted?** Will you run it on your own servers, or rely on a cloud service? This is decisive both for operational burden and for KVKK/BDDK. Pinecone and Qdrant offer strong managed options for RAG.

**Operational simplicity.** Does your team have the engineering capacity to keep this system running? pgvector is nearly zero extra burden for a team that already knows Postgres. Milvus is a serious operational commitment. Account for your team's realistic capacity.

**Cost.** The sum of license, infrastructure, operations, and scaling costs. Managed services are comfortable at first but bills can balloon as volume grows. Self-hosting takes effort upfront but can be predictable in the long run.

## Comparison table

So you can see all of this at a glance, I've gathered my field observations into a table. Figures are directional and vary with hardware/version:

| Criterion | pgvector | Qdrant | Milvus | Weaviate |
|---|---|---|---|---|
| Language / architecture | Postgres extension | Rust, standalone | Distributed, C++/Go | Go, standalone |
| Single-node latency | Good (up to ~10M) | Very good (~4ms p50) | Good (~6ms p50, better with GPU) | Good |
| Ideal scale | Up to ~10M vectors | Medium-large, strong single node | Billions, distributed | Medium-large |
| Hybrid search | Limited | Good | Good | Very good (its strength) |
| Filtering | Medium | Very good | Good | Good |
| Operational burden | Very low (if Postgres exists) | Low-medium | High | Medium |
| Managed option | Cloud Postgres offerings | Qdrant Cloud (strong) | Zilliz Cloud | Weaviate Cloud |
| Where it shines most | Those already using Postgres | Low latency + RAG | Massive distributed scale | Hybrid search + GraphQL |

## The rule of thumb: "pgvector if you already run Postgres, Qdrant if you don't"

This is the most common rule of thumb I give my clients: **If you already run Postgres, start with pgvector; if you don't, look at Qdrant.** This rule is a nice starting point that breaks decision paralysis.

The logic: if you already have Postgres in your infrastructure, adding pgvector is nearly free. You don't have to learn a new system, take on a new operational burden, or set up a new backup and security pipeline. Vectors sit side by side with your relational data, and you do both semantic and structural filtering in a single query. Up to 10M vectors, this architecture carries most projects.

If you don't run Postgres and you're setting up vector infrastructure from scratch, then a standalone solution makes sense. Here Qdrant, with its low latency, strong filtering, and good developer experience, is the most balanced choice in most RAG scenarios. If you want a managed solution, Qdrant Cloud or Pinecone are strong options.

This rule has exceptions, of course. If you know from the start you'll scale to billions of vectors, consider Milvus directly rather than starting with pgvector and migrating later. If hybrid search is your top priority, put Weaviate on the table. But for most projects, this two-item rule gives the right starting point.

## Under the shadow of KVKK and BDDK: data residency and access control

Now I come to the most critical part of the Turkish context: regulation. In regulated sectors, choosing a vector database is not just a performance decision but a compliance decision.

**Data residency.** In RAG systems, vectors are actually semantic representations of your documents, customer data, and corporate knowledge. And it can be possible to partially recover the original text from these vectors. So your vector database is really an extension of your sensitive data. From a KVKK standpoint, where this data is kept is critical. In banking under BDDK regulations, keeping data domestic, in a controlled environment, is often mandatory.

This is where the self-hosting vs. managed dilemma takes on a legal dimension. A managed cloud vector database (especially one hosted abroad) is operationally comfortable but may violate data-residency requirements in a regulated sector. A bank sending its customer documents to a managed service abroad is a serious compliance risk. So in fields like banking, insurance, and healthcare, I generally recommend self-hosting: running pgvector in your own data center or Qdrant/Milvus on your own infrastructure.

**Access control.** Who can access your vector database? Which user can query which documents? In RAG, this is an overlooked but critical topic. If you don't enforce access control at the vector layer, a user could theoretically see, in query results, the content of documents they shouldn't access. pgvector inheriting Postgres's mature access-control mechanisms is a serious advantage here. In other engines you have to carefully set up access control either at the application layer or via metadata filtering.

## Evaluation should drive the decision: recall@k and latency SLOs

The essence of this whole piece can be gathered into one sentence: **evaluation, not benchmarks, should drive the decision.** And evaluation should be done on your own data.

This is the warning I repeat most in the field. The chart on a vendor's marketing page is not enough to make your decision. Because that chart was probably measured on data very different from yours, with patterns different from your query patterns, at a recall target different from yours. Vector database performance is incredibly sensitive to data distribution. The same engine can be a leader on one dataset and mediocre on another.

So before you choose, I recommend measuring two metrics on your own data:

**recall@k.** How well does the engine find the k most relevant results? To measure this you need a "gold standard": a set of queries and, for each query, the truly relevant documents. Measure how well the top k results the engine returns overlap with this gold standard. recall@k is a direct measure of your system's quality; because in RAG, an engine that fetches the wrong documents is useless even if it's the fastest engine in the world.

**Latency SLOs.** What's your application's acceptable latency limit? Measure p50 (median) and p99 (worst 1%) latencies on your own data, at your own query volume. An engine's p50 may be great but its p99 may be a disaster; and p99 often determines user experience. Define your SLO from the start (e.g. "99% of queries must return under 50ms") and screen candidates against that SLO.

These two metrics are the two pans of a scale. To increase recall you search the index more thoroughly, which increases latency. The right point depends on your application's requirements. But the key is this: that point should be set by your data, not the vendor.

## How to set up an evaluation pipeline

So how do you set up evaluation on your own data in practice? The steps I apply in the field:

First, collect a representative query set. The kind of diverse, realistic questions your actual users might ask. Not artificial, ideal questions; the messy, ambiguous, edge-case questions the system will really encounter. The more realistic this set, the more valuable your evaluation.

Then build a gold standard for these queries. For each query, manually mark the truly relevant documents or derive them from an existing source. This takes effort but is indispensable; without a gold standard you can't measure recall.

Then run your candidates on the same data, the same query set, the same hardware. For each, measure recall@k and the latency distribution (p50, p95, p99). And critically: run each engine in its own optimal configuration. Comparing one engine with default settings against another with optimized settings isn't fair.

Finally, evaluate the results together with your filtering and hybrid-search needs. Not raw speed, but performance under your real workload matters. An engine may be fast on pure vector search but collapse on filtered queries; and if your business requires filtered queries, that engine is wrong for you.

## A real-world trap: index settings

One of the sneakiest mistakes I see in the field is ignoring index parameters. Popular vector indexes like HNSW have dials that directly affect the tradeoff between recall and latency. Set them wrong and you can make a great engine look terrible, or vice versa.

So when evaluating an engine, you have to tune its index parameters to your recall target too. When comparing two engines, run both at the same recall level and compare their latencies, or run both at the same latency budget and compare their recall. Saying "engine A is faster" is meaningless without stating the recall level. Maybe A is faster but at 85% recall, while B is a bit slower but at 99% recall. If your application requires 99% recall, A's speed is worthless.

## The cost reality: hidden bills

Finally, let me add a few field warnings on cost. Managed vector databases are attractive at first; no setup, no operations, works immediately. But as volume grows, bills can balloon fast. Especially as vector count and query volume rise, managed-service costs can climb well above self-hosting. So look not at the initial cost but at the scaled cost.

Self-hosting takes engineering effort upfront but is predictable in the long run. pgvector is nearly marginal cost for a team already running Postgres. Self-hosting Qdrant and Milvus takes a bit more effort but offers full control and predictable cost. When you decide, calculate the three-year total cost of ownership; not just the first month's bill.

## Embedding model choice: often the overlooked real determinant

There's a blind spot I see again and again in the field: teams debate for weeks which vector database to choose but ignore the embedding model, which is the real quality determinant. Yet the quality of the results your RAG system finds is determined less by the database than by the embedding model that produces the vectors. The wrong embedding model renders even the world's fastest and most accurate vector database useless; because the database only searches among the vectors it's given, and if those vectors are bad, the result is bad too.

This is especially critical in the Turkish context. Most popular embedding models are trained English-centric; their performance at capturing semantic similarity in Turkish text can be lower than in English. If you're building a Turkish RAG system, you must also evaluate your embedding model on your own Turkish data. "This model leads the English benchmark" doesn't mean it leads on your Turkish documents. When choosing a vector database, don't think of the embedding-model choice separately; the two together determine the system's quality, and you must measure both on your own data.

Embedding dimension is also a decision. Higher-dimensional embeddings usually offer richer semantic representation but increase both storage and search cost. When choosing a vector database, account for how efficiently your embedding model's dimension is handled in that database. Some engines scale gracefully at high dimensions, while others struggle on latency.

## Quantization and storage: the hidden cost of millions of vectors

As scale grows, the raw storage cost of vectors becomes an insidious problem. Millions of high-dimensional vectors consume serious memory and disk. This is where quantization comes in: by compressing vectors into a format that takes less space, you both lower storage cost and increase search speed. In return you may see a small drop in recall.

Different vector databases offer different quantization strategies: scalar quantization, product quantization, and binary quantization. Qdrant offers flexible options here; you can significantly reduce memory at large scale. When evaluating an engine, measure quantization's effect on recall on your own data too. Because as compression gets more aggressive, recall can drop; you have to find the acceptable balance for your application. In a legal search system requiring high recall, aggressive quantization is risky; but in a recommendation system where you have some flexibility on recall, quantization can save you a lot of cost.

## Reindexing and update burden

RAG systems aren't static; documents get added, updated, deleted. An overlooked topic in the field is how a vector database copes with these changes. Some engines can update the index efficiently when a new vector is added; others require periodically rebuilding the entire index, which at large scale is a serious operational burden.

If your data changes frequently (say hundreds of new documents daily), this update burden should directly affect your choice. pgvector inheriting Postgres's transaction mechanisms is an advantage for consistent updates. Qdrant and Milvus also support live updates but their behavior and performance impact differ. Include in your evaluation pipeline not just static search performance but update scenarios too. After the system goes live, how it behaves with continuously changing data will matter far more than day-one empty-index performance.

## Multi-tenant architectures and isolation

Another requirement I often meet in enterprise projects is multi-tenancy: keeping multiple customers' or departments' data in a single vector database, isolated from each other. This matters both for cost efficiency and for access isolation under KVKK. One customer's vectors must never appear in another customer's query results.

Different engines solve this differently: some offer collection-based isolation, others provide logical separation via metadata filtering. Qdrant's collection and payload-filtering capabilities are strong in this scenario. pgvector can set up robust isolation using Postgres's schema and row-level security mechanisms, which is priceless for auditable access control in regulated sectors. If you're designing a multi-tenant system, verify from the start whether your chosen engine's isolation model meets your security requirements; adding isolation later is one of the most expensive architectural debts.

## Escaping decision paralysis: a practical roadmap

All these criteria can feel overwhelming, so let me summarize the practical roadmap I give clients. First clarify your scale and regulatory constraints; these are the hardest boundaries. If you're in a regulated sector and data must stay domestic, managed offshore services are already eliminated. Then look at your existing infrastructure: if you have Postgres, pgvector is the lowest-friction start. If you're building new infrastructure and want low latency, Qdrant. If you need massive distributed scale, Milvus. If hybrid search is the top priority, Weaviate.

Then test one or two candidates on your own data, with your own queries, at your own recall target. Trust this test, not the synthetic benchmark. And finally, calculate the three-year total cost of ownership; not the first month, but the scaled version. This disciplined process breaks decision paralysis and protects you from a choice you'll regret in six months. Choosing a vector database is a far more strategic decision than it looks; but approached with the right framework, quite manageable.

## A synthesis from the field

Looking back, what separates the teams that choose vector databases right from the rest is that they trust their own data, not vendor charts. They honestly assess their scale: if under 10M and using Postgres, they stay on pgvector, because simplicity is a virtue. If building new infrastructure and wanting low latency, they look at Qdrant. If they need massive distributed scale, they turn to Milvus; if hybrid search is critical, Weaviate. But no decision is finalized without the recall@k and latency SLOs they measured on their own data.

In regulated sectors, the choice is a compliance decision beyond performance. Under KVKK and BDDK, data residency, access control, and auditability often make self-hosting mandatory; and this shows once more how valuable it is that pgvector inherits Postgres's mature security mechanisms.

If you're about to choose a vector database today, my advice is clear: start with the "pgvector if you already run Postgres, Qdrant if you don't" rule, but validate that rule with recall@k and latency SLOs on your own data. Trust not synthetic benchmarks but your own evaluation pipeline, built with a representative query set and a real gold standard. Account for your regulatory constraints from the start. And remember: not the fastest engine, but the engine that's right at your scale, at your recall target, within your regulatory framework, wins. The teams that build this discipline grow their RAG systems smoothly for years; those that don't rewrite everything six months later.