# Choosing a Vector Database in 2026: pgvector, Qdrant, Milvus, and Pinecone Compared > Source: https://sukruyusufkaya.com/en/blog/vektor-veritabani-secimi-2026-pgvector-qdrant > Updated: 2026-07-15T04:42:09.936Z > Type: blog > Category: yapay-zeka **TLDR:** Choosing a vector database depends on scale, latency and operations. I compare pgvector, Qdrant, Milvus and Pinecone with 2026 benchmarks and a decision framework. **TL;DR —** Choosing a vector database is not a "best product" contest; it is a balancing act between scale, latency, operational maturity, and cost. My observation from the field is clear: for most organizations, **up to 10 million vectors**, the smartest starting point is **pgvector**, because it adds vector search to your existing Postgres with zero new infrastructure. If you want **low latency and advanced filtering**, the Rust-written **Qdrant** stands out (p50 around ~4ms). At **billion-vector** scale, with GPU acceleration and the richest range of index algorithms, **Milvus** comes into play. If you never want to manage infrastructure and data residency is not a concern for you, **Pinecone** is the smoothest fully-managed option. In a Turkey and KVKK context, self-hosted options (pgvector, Qdrant, Milvus) strengthen your hand on data residency compared to managed Pinecone. Below I cover each honestly, with strengths and limits, a decision framework, and a scenario-based selection guide. All benchmark numbers are directional and configuration-dependent; re-measure with your own data on current versions. ## Why I'm Writing This In nearly every organization I've consulted for over the past two years, I've seen the same scene: a team starts a RAG (Retrieval-Augmented Generation) project with enthusiasm, runs a demo, and then, when it's time to go to production, gets stuck on the question "which vector database should we use?" Contradictory benchmarks online, marketing pages where each declares itself number one, forum threads where people contradict each other's experiences... In the end, the decision often comes down to whose blog post someone read that week, or which vendor sent the most aggressive email. My goal in this post is to cut through that noise. I won't tell you "this one is the best," because there is no such answer. Instead, I'll give you a thinking framework **so you can make your own decision.** I'll cover the four main players (pgvector, Qdrant, Milvus, Pinecone) with observations from the field and honest strengths and weaknesses. A warning up front: all the performance numbers here are directional. In 2026, every one of these engines shipped a major release; a number you see in a benchmark may come out completely differently on your hardware, with your data distribution, with your index settings. So read this post as a "decision map," not a "definitive scoreboard." ## How to Think About the Choice When you treat the vector database choice as an engineering decision, you need to think across four axes. These four axes form the skeleton of the rest of this post: 1. **Scale:** How many vectors will you store? 1 million, 10 million, 1 billion? This is the single most determining factor. Because an engine working perfectly at 1 million does not mean it will work perfectly at 500 million. As scale grows, index structure, memory management, and distributed architecture become critical. 2. **Latency and throughput (p99 latency & QPS):** When a user fires a query, how quickly must the answer return? Average (p50) latency is misleading; what really matters is **p99**, the slowest one percent. How many queries (QPS — queries per second) must you serve simultaneously? A chatbot and a batch analysis job have very different requirements. 3. **Operational readiness:** High availability (HA), multi-tenancy, role-based access control (RBAC), backups, monitoring... Who will manage these? Do you have people on your team who can stand this up and respond when the alarm goes off at 3 a.m.? This is the axis most organizations underestimate but that later burns them the most. 4. **Cost:** Not just license or subscription; servers, memory, engineering time, maintenance... A managed service looks expensive at first glance, but we usually forget the hidden cost of running your own infrastructure (especially engineer hours). > Advice from the field: Write these four axes on a whiteboard in a meeting and put a number or a clear sentence for each, for your own project. "Scale: 40 million vectors within 18 months," "p99 target: under 50ms," "Ops: we have a 2-person platform team," "Budget: X per month." The moment you fill in this table, two of the four options are already eliminated. The decision becomes easier than you thought. Now, keeping this framework in mind, let's take the four engines one by one. ## pgvector: The Power of the Postgres You Already Have pgvector is the option I say "start here first." Why? Because most organizations already have a PostgreSQL database. pgvector adds vector search capability to this existing Postgres as an extension. That means **zero new infrastructure.** You don't stand up a new service, you don't take on a new operational burden, there's no entirely new system for your team to learn. **Strengths:** - **Operational simplicity.** If you already manage Postgres, you already manage pgvector. Backups, replication, monitoring, access control — all with familiar tools, familiar processes. - **ACID guarantees.** You can manage your vectors consistently within the same transaction as your relational data (user information, metadata, permissions). This is an enormous advantage overlooked in many enterprise scenarios. Vector and business data in one place, with one consistency model. - **SQL ecosystem.** JOINs, filters, your existing queries... They all work as is. You can embed vector search inside a normal SQL query. - **Quite good up to ~10 million vectors.** Let's be honest, this is a scale that more than covers the needs of the vast majority of organizations. **Limits:** - When scale grows very large (tens to hundreds of millions of vectors, high concurrent query load), it can fall behind purpose-built (designed only for vectors) engines. On raw vector throughput, specialized engines are ahead. - On very high-QPS, pure vector-heavy workloads, Postgres's general-purpose architecture can create a ceiling. - Extensions like pgvectorscale raise this ceiling significantly (I'll touch on this in the benchmark section below), but that means additional configuration and a learning curve. > My practical rule: if you already use Postgres and your vector count will stay below 10 million for the foreseeable future, **start with pgvector without looking for anything else.** Prematurely setting up a specialized vector database is buying operational complexity for a problem you don't have. You migrate when the need arises; that day may never come. ## Qdrant: The Speed and Filtering Master, Written in Rust Qdrant is the engine that strikes the balance I like most among purpose-built vector databases. Being written in Rust gives it memory safety and predictable, low-latency performance. In numbers: Qdrant has **among the lowest p50 latencies** of purpose-built vector databases — around **4ms**, with p99 around **~25ms**. In a 10-million-vector benchmark, on the p99 side, **Qdrant measured ~12ms**, Weaviate ~16ms, Milvus ~18ms. These numbers are of course configuration-dependent and directional, but they reflect Qdrant's character on the latency side well. **Strengths:** - **Low and predictable latency.** The performance Rust brings shows itself especially in tail latencies like p99. On common workloads, it can be **~10–25% faster** than Weaviate and Milvus. - **Advanced payload filtering.** This is Qdrant's real star. It's very good at combining vector search with complex filters over metadata (payload). Queries like "the most similar 10 results among documents in this category, after this date, belonging to this user" are Qdrant's natural domain. - **Quantization support.** It lets you significantly reduce your memory footprint and optimize cost. With scalar and binary quantization, you can fit large datasets into smaller memory. - You can run it self-hosted, and a managed option is also available with Qdrant Cloud. **Limits:** - Compared to pgvector, it's still a new service; standing it up, monitoring it, and scaling it brings additional operational load to your team. - At billion-vector scale, it doesn't have Milvus's advantages in GPU acceleration and index variety; at that extreme, Milvus is more suitable. > I especially recommend Qdrant in these situations: if you heavily combine complex metadata filtering with vector search, and p99 latency is a critical SLA item for you. My field experience on the filtered-search side has been very positive. ## Milvus: The Address for Billion-Vector Scale and GPU Milvus is the engine that sits at the table when we talk about scale beyond "large," into "massive." If you work with billions of vectors — think: all product embeddings of a giant e-commerce catalog, a national-scale image search system, or an enormous scientific paper/patent collection — the scalability and flexibility Milvus offers make a serious difference. **Strengths:** - **GPU acceleration.** Milvus can leverage GPUs for indexing and search operations. On very large datasets, this can dramatically improve both index build time and query throughput. - **The richest range of index algorithms.** IVF variants, HNSW, disk-based indexes, and more... Milvus gives you the freedom to fine-tune the index type to your workload. This flexibility is genuinely valuable for squeezing performance at extreme scale. - **Distributed architecture.** Designed from the ground up for horizontal scaling. You can separate storage and compute, and scale components independently. **Limits:** - **Operational complexity.** Milvus's power is also its cost. It's a distributed, multi-component system; setting it up, tuning it, and operating it correctly requires a serious platform engineering investment. For a small team, this can be a heavy burden. - **Over-engineering at small scale.** If you have 5 million vectors, setting up Milvus is like renting an 18-wheeler for a bike ride. You'd be buying complexity whose power you can't use. > My clear rule for Milvus: if your scale exceeds hundreds of millions and is heading toward a billion, and you have a platform team to operate that scale, Milvus is a strong choice. Otherwise, you'd probably be setting up more than you need. ## Pinecone: The Smoothest Managed Experience Pinecone is a fully-managed vector database service. The core promise here is simple and powerful: **manage no infrastructure.** No servers, no index-tuning headaches, no scaling worries. You call the API, and Pinecone handles the rest. With sub-10ms p50 latency levels, it's more than fast enough for most applications. **Strengths:** - **Zero infrastructure management.** This is an enormous advantage for small teams and product teams that want to move fast. Your team can focus on the product instead of operating a vector database. - **Smooth operations.** Scaling, high availability, updates — all the service's responsibility. The alarm doesn't ring at 3 a.m. - **Sub-10ms p50 latency.** Performance is plenty for a very wide range of applications. - Fast start: the time from idea to a working prototype is very short. **Limits:** - **Data residency and control.** Your data is in a third-party managed cloud. In a Turkey and KVKK context, this is a serious matter for sensitive data (I've dedicated a separate section to this below). - **Cost model and dependency.** As scale grows, managed service cost can rise quickly. There's also vendor lock-in risk; if you want to migrate later, that's a cost. - **Less low-level control.** You don't have the fine-tuning freedom that self-hosted options give in index parameters and infrastructure placement. > I recommend Pinecone when: you're a small team or one that doesn't want to manage infrastructure, you need to ship fast, and your data carries no constraint in terms of data residency. If you can say "operating a vector database is not my job," Pinecone sells exactly that philosophy. ## Comparison Table: Placing the Four Engines Side by Side The table below summarizes the four engines across the axes we've discussed in this post. **Important caveat:** the latency values here are directional and configuration-dependent; be sure to re-measure on your own hardware, with your own data, on current versions. | Engine | Typical p50 latency | Scale sweet spot | Operational load | Deployment model | Best for | |---|---|---|---|---|---| | **pgvector** | Depends on Postgres, varies by workload | Up to ~10M vectors | Very low (existing Postgres) | Self-hosted (Postgres extension) | If Postgres exists, operational simplicity, ACID | | **Qdrant** | ~4ms (p99 ~25ms) | 10M+, low-latency focused | Medium (new service) | Self-hosted or Qdrant Cloud | Low p99 latency + advanced filtering | | **Milvus** | ~18ms (in 10M benchmark) | Hundreds of millions–billion | High (distributed system) | Self-hosted (and managed options) | Billion scale, GPU, index variety | | **Pinecone** | Sub-10ms | Wide range, managed | Almost zero (managed) | Fully-managed cloud | Fast launch without managing infrastructure | Read this table not as a "who won" list, but as a "which one fits which need" map. Each row can be the right answer for a different organization. ## Benchmarks: What to Watch When Looking at Numbers Now we've reached the most dangerous section: benchmark numbers. Why dangerous? Because benchmarks are misleading when torn from context — indeed, they can be made deliberately misleading. I'll give you a few concrete numbers, but I'll put **"directional and configuration-dependent"** in bold before each one. **Latency side (around 10M vectors):** - Qdrant p99 **~12ms**, Weaviate **~16ms**, Milvus **~18ms**. Qdrant's Rust-based architecture gives it an advantage in tail latencies. Overall, Qdrant can measure **~10–25% faster** than Weaviate and Milvus on common workloads. **High-scale side (50M vectors):** - In one benchmark, at a 99% recall target, **Qdrant delivered ~41.47 QPS** while **pgvectorscale delivered ~471 QPS** — that is, an **order-of-magnitude difference**. This is a striking result, but extremely configuration-dependent. pgvectorscale's performance in this scenario shows how powerful a well-tuned Postgres-based solution can be. Even these two data points tell you: **there is no single "winner."** If latency is critical and you're at medium scale, Qdrant shines; in a certain high-recall throughput scenario, pgvectorscale can surprisingly pull ahead. The numbers tell entirely different stories depending on how the question is framed. > **My most important warning:** In 2026, **every one of these engines shipped a major release.** So every benchmark you find online — including this post — may already be outdated even as you read it. Never make these numbers the sole basis of a purchase decision. The only right thing to do: **re-benchmark with your own data, on your own hardware, on current versions, with your own query patterns.** Spending a week to set up a PoC (proof of concept) is far cheaper than living with the wrong engine for six months. When reading benchmarks, ask these questions: Which version? Which hardware (CPU/GPU, memory)? Which recall target? Which vector dimension and count? Filtered or unfiltered? Single node or distributed? If you don't know the answers to these questions, that benchmark tells you nothing. ## Decision Framework: Scale, Latency, Operations, Cost Now let's turn the four opening axes into a concrete decision flow. Answer these questions in order for your project: **1. The scale question — How many vectors?** - **< 10M and Postgres already exists:** start with pgvector. Discussion over, at least for now. - **Between 10M–100M:** Qdrant (if you're latency/filtering focused) or a well-tuned pgvector/pgvectorscale. Pinecone is also a strong managed alternative. - **100M–billion+:** seriously consider Milvus, especially if you need GPU and index flexibility. **2. The latency and throughput question — What is your p99 target and QPS?** - If you have a strict p99 SLA (e.g., under 25ms) and do filtered search, Qdrant is strong. - If you need very high QPS and high recall together, test pgvectorscale and Milvus with your own data. Look at **p99**, not the average, and at behavior under load. **3. The operations question — Who will run it?** - No platform team, or a small one? Choose a managed path: Pinecone or Qdrant Cloud. Or add no new service and stay on pgvector. - Do you have a strong platform team and want control? Self-hosted Qdrant or Milvus makes sense. - List your HA, multi-tenancy, and RBAC requirements up front. Each engine's maturity here differs; verify that the engine you choose meets these features at your level of need. **4. The cost question — What is the total cost of ownership (TCO)?** - Place the managed service's subscription bill side by side with self-hosted's hidden cost (servers + memory + **engineer hours** + maintenance + on-call). - At small scale, managed usually comes out cheaper (engineer time is expensive). At very large scale, self-hosted can provide a cost advantage, but only if you can operate it efficiently. When you answer these four questions honestly, the four options usually narrow to one or two. That's when it's time to set up a PoC and take your own benchmark. ## KVKK, Data Residency, and Self-Hosted vs. Managed If you're an organization operating in Turkey, this section may be even more important for you than technical performance. What do you store in your vector database? In most RAG applications, these embeddings are derived from internal documents, customer records, contracts, emails. That is, **sensitive data.** And this data, even when turned into embeddings, often remains strongly correlated with the original content. Under the KVKK (Personal Data Protection Law) framework, sending embeddings that contain personal data to a managed service abroad raises serious legal questions regarding data transfer and residency. This is exactly where **self-hosted options gain an advantage:** - **pgvector, Qdrant, and Milvus** can be run on your own infrastructure — in your own data center or in a cloud region in Turkey. This makes meeting data residency requirements and keeping data within borders much easier. - A fully-managed service like **Pinecone** offers smooth operations, but your data is located in the provider's cloud. If sensitive personal data is involved, you must discuss this on-prem vs. cloud trade-off with your legal and compliance teams. > My practical recommendation: bring your legal/compliance team to the table at the very start of the project. The answer to "are these embeddings considered personal data, and if so, where can they reside?" can determine half of your technical options before you write a single line of code. In the field, I've seen projects where a perfect technical decision came back at the compliance stage; that's one of the most expensive mistakes. This doesn't mean "managed bad, self-hosted good." It's a **trade-off.** Managed gives you operational comfort, at the expense of control and residency. Self-hosted gives you control and residency, and loads you with operational burden. The right answer depends on your data's sensitivity and your team's capacity. ## A Selection Guide by Scenario Now let's make it concrete. I'm sharing the scenarios I most frequently encounter in the field, and which way I lean in each: **Scenario 1 — "We're a SaaS using Postgres, adding a RAG feature, a few million documents."** → **pgvector.** Add no new infrastructure. Install the extension on your existing Postgres, benefit from ACID consistency, ship quickly. As long as you stay below 10M, this is the most efficient path. **Scenario 2 — "A real-time recommendation/search system, strict p99 SLA, heavy metadata filtering, ~30M vectors."** → **Qdrant.** Low p99 latency and advanced payload filtering are exactly for this scenario. You can run it self-hosted and keep control, optimizing cost with quantization. **Scenario 3 — "National-scale image/document search, billions of embeddings, strong platform team."** → **Milvus.** GPU acceleration and index variety make a difference at this scale. It makes sense because you have a team to handle the operational complexity. **Scenario 4 — "We're a small startup, no one to manage infrastructure, need to ship a fast MVP, low data sensitivity."** → **Pinecone.** The fastest launch with zero infrastructure management. Your team focuses on the product, not on operating a vector database. **Scenario 5 — "We're in a regulated sector in Turkey like finance/healthcare, data must stay onshore."** → **Self-hosted pgvector, Qdrant, or Milvus** — depending on your scale. The data residency constraint most likely removes managed Pinecone from the table. If scale is below 10M, pgvector; if filtering/latency is critical, Qdrant; if you're at billion scale, Milvus. These scenarios are templates; yours may not be exactly one of them. But when you overlay the four axes (scale/latency/ops/cost) with the residency constraint, you'll clearly see which way your own scenario leans. ## Common Mistakes Mistakes I've seen in the field, the same ones again and again. Knowing them up front will save you a lot of time and money: - **Premature optimization.** Setting up a billion-scale Milvus cluster when you have 2 million vectors. You're buying complexity you don't need. You migrate when scale arrives; maybe it never does. - **Looking at average latency and forgetting p99.** What ruins user experience is not the average, but the slowest one percent. Always look at **p99** and behavior under load. - **Blindly trusting someone else's benchmark.** Deciding based on a blog number with unclear context. If you haven't measured with your own data, on the current version, with your own queries, that number means nothing for you. - **Underestimating operational load.** Saying "we'll set it up and it works." HA, backups, monitoring, RBAC, updates, on-call... Entering self-hosted without planning who will manage these and how is a bridge that burns six months later. - **Leaving KVKK/data residency to the end.** After making the technical decision and building the architecture, legal says "this data can't leave the country." Bring this conversation to the very front. - **Ignoring the filtering need.** Most real applications do filtered vector search, not pure vector search. If you neglect the engine's filtering performance (especially at scale), you'll face a surprise in production. - **Not accounting for vendor lock-in.** Getting deeply tied to a managed service is easy; getting out is hard. Thinking about an exit scenario from the start protects your future flexibility. - **Choosing without thinking about the embedding model and dimension.** Vector dimension directly affects memory cost and index performance. Making the database choice independently of your embedding strategy is half a decision. ## How to Proceed: A Concrete Action Plan If you've read this post and are asking "okay, now what do I do?", here's a step-by-step starting plan from the field: 1. **Fill in the four axes.** Write on the whiteboard: scale (today and 18 months out), p99 target and QPS, your operational capacity, budget. Put a concrete number/sentence for each. 2. **Clarify the residency constraint.** Talk to the legal/compliance team: is your data personal data, and where can it reside? If this answer narrowed your set of options, let it — that's a good thing. 3. **Identify two finalists.** After filtering through the four axes and residency, you're usually left with two engines. Let this post's scenario guide and table help you find those two finalists. 4. **Take your own PoC benchmark.** Set aside a week. Compare the two finalists with a sample of your own data, your own query patterns, on current versions, on your own hardware. Look at p99, behavior under load, and filtered-query performance. 5. **Design the operations.** For the engine you choose, write the HA, backup, monitoring, RBAC, update, and on-call plan. If this plan doesn't exist, the decision isn't complete. 6. **Start small, plan the migration.** In the first release, ship with the simplest sufficient solution (usually pgvector). But abstract your embedding and search layer so you can migrate to another engine when needed. This makes your future decisions cheaper. Choosing a vector database, when viewed with the right framework, is not frightening. Clarify the four axes, resolve residency, test the two finalists with your own data, design the operations, and start small. If you follow these steps, you'll have made a decision based on your own reality — not on whose blog post you read that week — and the right decision almost always emerges this way.