Choosing a Vector Database in 2026: pgvector vs Qdrant vs Milvus vs Weaviate for Production

TL;DR — If you are taking a RAG system to production in 2026, your choice of vector database is one of the decisions that shapes the whole project. Here is the short version. If you are already on Postgres and under ~10 million vectors, pgvector is the smartest default; you stay inside the same backups and operations you already run. For low-latency, filtered RAG, Qdrant is my first pick (p50 ~4 ms, p99 ~25 ms; roughly 10–25% faster than Weaviate or Milvus on common workloads). If you want mature, out-of-the-box hybrid search and integrated vectorizers, choose Weaviate. For billion-scale workloads, Milvus/Zilliz Cloud. For prototyping only, Chroma. But my most important warning is this: a fast database with poor recall is worthless. Set up retrieval evaluation first (precision/recall, context relevance, faithfulness), then argue about databases.

Hello. For years I have worked in the field on enterprise AI projects in Turkey; I build RAG (Retrieval-Augmented Generation) architectures at banks, insurers, and manufacturers, and I train their teams. I am writing this because I keep meeting the same question in the field: "Which vector database should we choose?" Behind that question there is usually a bit of panic, because the internet is full of dozens of benchmarks, a new tool every week, and contradictory advice. Today I want to cut through that noise for you. I am not going to hand you a marketing brochure; I am going to share observations from the field.

Let me say one thing up front: the right answer is not "the most popular one." It is "the one that fits your workload, your scale, and your team's capacity to operate it." One of the most expensive mistakes I have seen was a team working with just 400,000 document chunks who, because "we might scale to billions someday," stood up a complex, billion-scale distributed system and then spent six months keeping it alive. They could have spent those six months improving the product. Let us avoid that kind of mistake together.

Think of RAG like a library. A user asks a question, and you find the most relevant book pages and tell the language model, "look, answer based on these." The magic is in the "find the most relevant page" step, and that is exactly what a vector database does. But debating which tool to pick without understanding how it works is like buying a car without knowing anything about the engine. So let me summarize a few core concepts the way I explain them in the field, in the plainest terms.

Embeddings. We convert a piece of text, an image, or an audio clip into a sequence of numbers (a vector) that represents its meaning. "Credit card debt" and "paying the card statement" use different words but are close in meaning, so their vectors land close together too. This is the heart of RAG: not word matching, but semantic proximity. The dimension of the vector (say 768, 1024, 1536) depends on the embedding model you use, and that dimension directly affects both your storage cost and your search speed. A point often missed in the field: when you change the embedding model, you have to regenerate the entire index. That makes model choice an even more permanent decision than database choice.

ANN indexes (HNSW, IVF). You have 10 million vectors and you want the 10 closest to an incoming query vector. If you compare them all one by one (we call this "brute force" or exact nearest neighbor) you get the correct answer but slowly. Instead we use Approximate Nearest Neighbor (ANN) algorithms. You only need to know two:

• HNSW (Hierarchical Navigable Small World): connects vectors in a layered graph. Search starts at a few nodes in the top layer and moves down toward the target. It is very fast and gives high recall; it is the default for most production systems today. The cost is high memory consumption and a relatively expensive index build.
• IVF (Inverted File Index): first partitions the vector space into clusters, then at query time looks only at the most relevant few clusters. It uses memory more economically and is advantageous at very large scale, but its tuning (how many clusters to probe) directly affects recall. It is usually paired with quantization.

Filtering. In the real world, search is rarely just "find the semantically closest." There is almost always a condition: "within the documents this user is authorized to see," "only in post-2025 documents," "only in the HR policies department." This metadata filtering is where production RAG sweats the most. A database that looks brilliant in a benchmark but slows down in real life usually stumbles on filtered queries. This is one of the places where Qdrant shines: it combines filtering and vector search efficiently.

Quantization. Vectors are stored as 32-bit floating point numbers by default. Quantization represents those numbers with fewer bits (for example, 8-bit with scalar quantization, or 1-bit with binary quantization), dramatically reducing the memory footprint. In practice this means you can hold far more vectors on the same server and pull costs down. The price is a small recall loss, which for most workloads is more than recovered with re-ranking. In Turkey, where memory cost hurts because of the exchange rate, I treat quantization as a serious lever.

Hybrid search. Vector search captures meaning but misses some things: product codes, statute article numbers, proper names, abbreviations. When a user types "KVKK article 6," they are searching for exactly that string; semantic proximity is not enough here. So we combine vector similarity with classic keyword search (BM25) in a single query. This is called hybrid search, and it visibly improves recall for most RAG workloads. Weaviate, Qdrant, Turbopuffer, and Elasticsearch support it natively; among them, the most mature, out-of-the-box hybrid search experience is in Weaviate.

Recall vs latency tradeoff. These two are the two pans of a scale, and this tradeoff underlies everything I will say in this article. Recall means "what percentage of the relevant results I should have found did I actually find." Latency means "how quickly I returned the answer." Tune the ANN algorithm to search more and recall goes up but you slow down; make it search less and you speed up but risk missing relevant results. One of the biggest mistakes in the field is looking only at latency and declaring "so fast, wonderful" without ever measuring recall. A fast but wrong answer is more dangerous than a slow correct one, because it quietly erodes the user's trust.

Because "vector search" is not one problem but a family of problems. Some teams want to handle this inside Postgres without leaving their existing setup. Some teams have billions of vectors and enormous traffic. Some are chasing milliseconds because their product is real-time. Others just want to ship a prototype over a weekend to validate an idea. These needs are so different that no single tool can be first at all of them. So I will not tell you "the best vector database"; I will tell you "the best one for your situation." Let us go through them one by one.

This is the advice I give most often in the field, and usually the least exciting. pgvector is an extension that adds vector search to PostgreSQL. That means you are not standing up a separate system or opening a whole new world of operations to learn. You keep your vectors in the same database as your application data, under the same backup routine, the same access control, the same monitoring dashboard.

Do not underestimate the value of that. Bringing a new database system into an enterprise is not just a technical task; it involves backup policy, disaster recovery planning, security audits, on-call training, licensing and procurement. Each of those is weeks to months of work. pgvector removes almost all of that burden because your organization already knows how to run Postgres.

My practical rule is this: if you are under ~10 million vectors and already on Postgres, pgvector should be your default. Do not change it unless scale or workload forces you to. It supports HNSW indexing, lets you do metadata filtering with the full power of SQL (a big comfort in complex conditional queries), and lets you combine vector search with your relational data through JOINs. In a customer support system, being able to express "search within the documents belonging to this user's open tickets" in a single SQL statement is priceless.

Let me be honest about the limits too. Under very high concurrent query traffic and above tens of millions of vectors, it may not be as fast as purpose-built systems. HNSW's memory consumption and index build time become noticeable as your data grows. But let me be clear: most Turkish enterprises' RAG projects never reach those limits in their first year or two. Over-engineering up front "in case we need it later" is the most expensive mistake.

If you have decided to move to a purpose-built vector database, my default recommendation is Qdrant. The reason is simple: its field performance is very consistent, and it is especially strong on filtered search. Being written in Rust gives it a real edge in memory management and predictable latency.

Let us look at the numbers. Qdrant has among the lowest p50 latencies of purpose-built vector databases: around 4 ms p50, around 25 ms p99. On common workloads it is roughly 10–25% faster than Weaviate or Milvus. At 10 million vectors, P99 latencies compare like this: Qdrant ~12 ms, Weaviate ~16 ms, Milvus ~18 ms. These differences may look small, but in a real-time product, once you add the language model's answer-generation time on top, every millisecond in the retrieval layer flows straight into user experience.

The real reason I like Qdrant is not raw speed alone; it is that it runs filtering and vector search together efficiently. As I stressed earlier, almost no production search is filter-free. Access permissions, date ranges, department, language, document type. Qdrant embeds these conditions into the search process efficiently; unlike systems that shine in benchmarks and collapse under real filtered workloads, it holds its consistency here. Its quantization support is also mature, which is a serious lever for Turkish teams wanting to lower memory cost. It supports hybrid search natively as well.

It is also comfortable on the self-hosted side. It is easy to bring up with Docker, and its resource consumption is predictable. For organizations that cannot move data abroad under KVKK and must run on-prem, that matters a great deal; I will open a separate section on that shortly.

Weaviate is strongest where it offers the most mature out-of-the-box hybrid search experience. It provides the blending of vector similarity with BM25 keyword search directly, without you having to architect it by hand. I explained above how much hybrid search improves RAG quality; if your workload is full of content that needs exact matches, such as product codes, legal references, and technical terms, Weaviate's maturity here saves you time.

Its second strength is integrating embedding models (vectorizers) directly. You hand it text, Weaviate turns it into a vector with the appropriate module and stores it; you do not have to build a separate embedding pipeline. For teams that want to move fast and stand up a prototype with an architecture close to production, this comfort is valuable.

What is the cost? It is not as sharp as Qdrant in raw latency (recall the 10M-scale P99 numbers above: ~16 ms Weaviate, ~12 ms Qdrant). That gap may not be decisive in every project, but if you are on a real-time, highly latency-sensitive product, weigh it. My distinction is usually this: if your priority is mature hybrid search and an integrated vectorizer, choose Weaviate; if your priority is the lowest filtered latency, choose Qdrant.

Some workloads really are enormous. Hundreds of millions, even billions of vectors; constantly streaming data; a need for horizontal scaling. Milvus (and its managed cloud version, Zilliz Cloud) is designed for exactly this scenario, a system whose distributed architecture can carry billion-scale workloads. It supports different index types (HNSW, IVF variants, and more) and lets you scale its components independently.

But let us be honest: that power comes with operational complexity. Milvus's distributed architecture requires managing multiple components, and running it correctly demands serious DevOps maturity. Moving to Milvus when you have 10 million vectors is like renting a semi-truck for a two-person move; it does the job but brings you burden, not benefit. Managed Zilliz Cloud takes some of that load off. My advice is clear: consider Milvus once it is proven that you are actually going to billion scale, not based on a guess.

If you want to validate an idea over a weekend, prepare a demo, or show a team the RAG concept, Chroma is great. Its setup is nearly zero-friction; it comes up with a few lines of Python and the developer experience is very clean. I often use Chroma in my trainings when explaining concepts because it focuses attention on RAG logic rather than infrastructure.

But what I do not recommend Chroma for matters as much as what I do: do not make it the backbone of your heavy production workload, your high-traffic real-time system. It shines in prototyping and struggles at scale. The right tool for the right stage. Validating a prototype with Chroma and then going to production with pgvector, Qdrant, or Weaviate is a perfectly sensible path.

Think of the table below as the summary I sketch for a team in the first five minutes in the field. I explained the nuances above; here I gather them for a quick decision.

Database	Best for	Hybrid search	Scale	Hosting
pgvector	Teams already on Postgres; under ~10M	Limited (needs an add-on for BM25)	Comfortable up to ~10M vectors	Postgres almost everywhere: on-prem, cloud, managed
Qdrant	Low-latency, filtered RAG	Native	Tens of millions; consistent performance	Self-hosted (Docker) or managed cloud
Weaviate	Mature hybrid search + integrated vectorizer	Most mature, out-of-the-box	Tens of millions	Self-hosted or managed cloud
Milvus / Zilliz	Billion-scale, distributed workloads	Supported	Billions	Self-hosted (complex) or Zilliz Cloud
Chroma	Prototyping, demos, learning	Basic	Small/medium	Usually local / embedded

A reminder: this table is a starting point, not a verdict. Every tool keeps evolving; but these positionings are enough to help teams make the most accurate first decision.

Now we come to the most important section of this article, and I say it with emphasis: a fast database with poor recall is worthless. The most common mistake I see in the field is teams falling in love with benchmark numbers and latency charts while never measuring "is the system actually finding the right document?" A vector database can return an answer in 4 milliseconds, but if the results it returns are irrelevant, that speed only lets you produce the wrong answer faster.

So before the database debate, I want you to set up a retrieval evaluation regime. The core things you must measure:

• Precision: what percentage of the results you return are actually relevant? High precision means you are giving the language model clean context, not noise.
• Recall: what percentage of the existing relevant documents did you capture? Low recall means you never even presented the source of the correct answer to the system; no matter how good the model is, it cannot produce a correct answer based on a document it never saw.
• Context relevance: how well do the context chunks you return match the question? Irrelevant context both raises token cost and pulls the model in the wrong direction.
• Faithfulness: is the model's answer actually grounded in the context you provided, or is it making things up (hallucinating)? RAG's entire reason for existing is to tie the answer to the source; faithfulness measures that.

My practical recommendation: build a small but representative evaluation set (a golden set) of real question-answer pairs from your own data. Even fifty to a hundred well-chosen examples say a lot to start. Then run this set on every database and every setting change, measuring precision, recall, and faithfulness. See how these metrics move when you change an embedding model, turn on quantization, or enable hybrid search. Make the decision by measurement, not by gut.

Let me give an example. At one insurance client, the team had deployed Qdrant and was very happy with the latency. But answers to questions about policy coverage came back strangely incomplete. When we built the evaluation set, we saw recall was low: users were using specific terms like "damage deductible," and pure vector search was missing these exact-match terms. The solution was not to change the database; it was to enable hybrid search and add a re-ranking step. Recall rose markedly, and latency stayed acceptable. That is the kind of gain you can never see without measuring.

Now let us get to a very important topic, the specific realities of working in Turkey. Teams that skip these run the project into a wall at a later stage.

KVKK and data locality. Under the Personal Data Protection Law (KVKK), especially in banking, insurance, healthcare, and the public sector, where data is processed and stored is critical. Many organizations do not want to, or by regulation cannot, send customer data to a cloud service abroad. The good news here: most of the tools we discussed can be self-hosted. pgvector already runs inside your Postgres, meaning in your own data center or local cloud. Qdrant, Weaviate, and Milvus all have self-hosted options too; you can run them on your own servers without your data ever leaving. Before choosing the convenience of managed cloud, clarify your organization's data locality requirements with your legal and compliance teams; that is the key to getting the architecture right from the start.

The reality of on-prem operations. Running on your own servers also puts the responsibility on you: backups, version upgrades, scaling, monitoring, security patches. This is exactly where pgvector's "same Postgres operations" advantage is worth its weight in gold. For an organization already running Postgres, pgvector means zero new operational burden. If you are moving to a purpose-built system, Qdrant's predictable resource consumption and easy Docker setup make things easier for on-prem teams.

Cost and the exchange rate. Because cloud costs in Turkey are billed in foreign currency, the dollar/lira rate hits your budget directly. So memory efficiency matters more here than in many other parts of the world. Take quantization seriously: bringing 32-bit vectors down to 8-bit greatly reduces the memory footprint, meaning you hold more vectors on the same hardware and rent fewer servers. You can offset a small recall loss with re-ranking. Also, not building a system bigger than needed is a cost discipline in itself; remember the team that spent six months keeping a billion-scale distributed system alive for 400,000 vectors. The cost of those six months was far larger than any licensing difference.

Local cloud and hybrid scenarios. Local data centers and cloud providers in Turkey are steadily maturing. For sensitive projects where data must stay in the country, running a self-hosted vector database on a local cloud or in your own data center is a highly viable path. If you also need to run the language model locally, being able to keep the retrieval layer aligned with that and entirely under your control is a big advantage. pgvector and Qdrant are the pair I most often recommend for these fully-controlled scenarios.

Let me leave you a framework that proceeds not by gut but by a few concrete questions. Ask yourself these in order.

1. Are you already on Postgres and under ~10 million vectors? If yes, start with pgvector and close the debate right there. Do not move to anything else until scale or workload forces you. This is the right answer for most projects, and because it is the most boring, it is the most overlooked.

2. Is your primary concern low latency and heavily filtered search? Then look at Qdrant. If you are on a real-time product and filtering intensively by access permission, date, and department, Qdrant's consistency and speed will make you happy.

3. Is mature, out-of-the-box hybrid search and an integrated vectorizer decisive for you? If your content is full of exact-match terms and you do not want to build a separate embedding pipeline, Weaviate is a strong candidate.

4. Is it proven that you are going to billion scale? I say proven, not guessed. Then evaluate Milvus/Zilliz Cloud and be ready for the operational complexity.

5. Are you just shipping a prototype? Start with Chroma, validate the idea quickly, then move to a production tool.

And above these five questions there is a question zero that comes before them all: have you set up your retrieval evaluation regime? Without it you cannot know which database is better for you, because you have no real yardstick to compare against. Build your golden set first, measure precision/recall/faithfulness, then race the candidates against that yardstick.

Let me share a few notes I have distilled over the years that do not fit in the table.

Take your embedding model more seriously than your database. A wrong embedding model gives poor recall even on the world's fastest database; a good embedding model shines even on a modest one. If you work with Turkish content, measure the model's Turkish performance on your own data; do not let success on English benchmarks mislead you.

Do not underestimate re-ranking. Keeping the initial candidate set wide with vector search and then re-ranking those candidates with a stronger model is one of the few tricks that can improve recall and precision at the same time. As long as it fits your latency budget, it visibly raises quality in most projects.

Do not neglect your chunking strategy. Even the best database cannot extract good context from poorly chunked documents. Chunk size, overlap, preserving document structure; all of these directly affect your retrieval quality and often make more difference than the database choice.

And finally: keep your decision reversible. Separate the retrieval layer from your embedding pipeline and application logic with a clean interface. That way, if you later need to move from Qdrant to Milvus or from pgvector to Qdrant, you do not have to rewrite the whole system. Good architecture is less about making the right decision the first time and more about being able to fix a wrong decision cheaply. Measure, start small, listen to the data; the rest will follow.