Every RAG tutorial pulls the same move. It walks you through embeddings, chunking, retrieval — and then, right at the moment of truth, it says "now pick a vector database" and just... moves on. Like that's a coffee-order decision. Like you're choosing a font.
It's not. The database you pick decides how fast your queries come back, how much you bleed in infrastructure costs, and how miserable your life gets the day traffic triples. And here's the thing that took me a while to figure out while researching this: the database you start with is often not the one you ship. Teams migrate, sometimes more than once. Some of those moves are clean wins; some are weeks of pain and a postmortem doc.
So let's try to skip the regret. I spent a long time digging through benchmarks, production write-ups, and the trade-offs people only discover after the fact, and this is the guide I wish I'd had when I started: what each of these five — pgvector, Pinecone, Qdrant, Weaviate, and Milvus — is actually good at, where each quietly falls apart, and how to pick without drowning in a feature matrix.
I'll spoil the ending, because it's the most useful thing here: pick based on the infrastructure you already run, not the benchmark you just read. If you're already on Postgres, the answer is probably pgvector and you can almost stop reading. If you never want to touch infrastructure again, it's Pinecone. Everything past that is fine-tuning.
The cheat sheet, for the impatient
| If this is you | Use | The one-liner |
|---|---|---|
| Already on Postgres, under ~50M vectors | pgvector | One database, zero new problems |
| Want it to just work, will pay for that | Pinecone | Hand them a key, walk away |
| Self-hosting and obsessed with speed | Qdrant | The Rust one. It's fast. |
| Hybrid search is the whole point | Weaviate | Did keyword + vector before it was cool |
| Heading toward a billion vectors | Milvus | Built for the scale that breaks everything else |
Now the actual reasoning.
First, stop staring at the benchmarks
I get the pull. The benchmarks are right there, with their satisfying little bar charts, and one database is 3ms faster than another and that feels like a decision. It mostly isn't. At the scale almost everyone actually operates, every database on this list is fast enough that your users will never feel the difference. The latency war is largely fought over workloads you don't have yet.
What actually decides this — in roughly this order — is four boring questions:
What do you already run? If Postgres is already humming along in your stack (and if you're a full-stack dev, it probably is), bolting on a second database means a sync layer, separate backups, and a whole new thing that can page you at 3am. That gravity is real, and it usually wins.
Do you want to run infrastructure at all? Some people find ops satisfying. Some people would rather light money on fire than configure another cluster. Both are valid. Be honest about which one you are.
How big does this actually get? Under 10 million vectors, genuinely anything works. Between 10 million and a billion, the field thins out fast. Past a billion, you've got maybe two real options.
Do you need hybrid search? This one sneaks up on people. Pure semantic search is great until a user types an exact product ID or a version number and your "vibes-based" retrieval shrugs. More on this later, but file it away.
Answer those four honestly and the database basically picks itself. Here's each one against that lens.
pgvector: the answer that's almost boring enough to be right
pgvector isn't a database. It's a Postgres extension — you teach the database you already have how to do vector search, and that's the whole trick. No new service. No sync layer. No 2am pages from a system you provisioned in a hurry and never fully understood.
Why it's so often the right call. Your vectors sit right next to your actual data, so you can query both in a single transaction, your existing backups already cover them, and filtering is just a SQL WHERE clause — joins, subqueries, the works. The old "Postgres is too slow for vectors" complaint is genuinely outdated; it comes from the bad-old-days IVFFlat era. Once HNSW indexing landed, pgvector started matching dedicated databases at a million vectors, and with the pgvectorscale extension it holds its own well past that — competitive throughput at 99% recall on tens of millions of vectors. For a huge share of RAG projects this is the right answer, and its only real crime is being unexciting.
Where it starts to hurt. Push past a couple million vectors on one box and index builds start taking twenty-plus minutes, and Postgres's VACUUM process starts elbowing your queries for resources. There's also a subtler trap: pgvector filters after it searches, so a picky filter on a big collection means scanning a pile of candidates to hand you back a handful. Somewhere around 50–100 million vectors you'll be reaching for read replicas, partitioning, or the exit.
Use it if: you're on Postgres, under ~50M vectors, and you don't need to win a latency contest. Most teams are exactly this and don't realize it.
Pinecone: pay money, make the problem disappear
Pinecone basically invented the managed-vector-database category and still sets the bar for it. You get an API key, you make an index, you throw vectors at it, you query them back. There's nothing to size, nothing to tune, nothing to keep alive. That's not a feature list — that's the entire pitch, and it's a genuinely good one.
Why people love it. "I need a vector database and I refuse to think about it any further" is a completely legitimate position, and Pinecone is built precisely for that person. It scales to billions of vectors, it does hybrid search, it's got the enterprise compliance checkboxes. You offload the whole operational headache to someone whose entire job is keeping it up.
The catch — and there's a real one. It's closed-source and there's no self-hosting, full stop. Your data lives in their cloud, and if their pricing shifts or they have a bad day, you have no plan B. The serverless tier swaps latency for convenience and pins your recall at around 90% with no knob to turn — Pinecone just doesn't let you touch the HNSW internals. Writes are eventually consistent, so freshly-added vectors take a beat to show up. Filtering is weaker than SQL (no joins, no subqueries), so anything fancy spills back into your application code. And the bill grows with you, sometimes faster than you'd like.
Use it if: not running infrastructure matters more to you than tuning control, and you've made peace with lock-in as the price of never thinking about this again.
Qdrant: the fast one, and it knows it
Qdrant is open-source, written in Rust, and built from day one to do vector search and basically nothing else. That focus shows.
Why it's appealing. It's the speed leader of the open-source pack — lowest p50 latency of the bunch, and the gap actually widens under heavy query load where it matters most. But the real party trick is filtered search: Qdrant runs your filters inside the search traversal instead of bolting them on afterward, so the exact "find me similar shoes, but only the red ones in stock" query that makes pgvector sweat stays snappy here. Add binary quantization that can shrink memory dramatically, plus newer cloud features like GPU-accelerated indexing and multi-AZ failover, and you've got a lot of database for the money. The free tier is the most generous on this list, too.
The honest downside. The ecosystem is younger. You'll find fewer Stack Overflow threads at midnight, fewer random blog posts that happen to solve your exact problem — though LangChain and LlamaIndex both support it just fine, so you're not in the wilderness. And some teams have reported friction under really heavy concurrent writes, so if you're write-hammering it, test that specifically before you commit.
Use it if: you'll happily run your own infrastructure, you want the best performance per dollar, and fast filtered search is central to what you're building.
Weaviate: the one that wants to be your whole pipeline
Weaviate is open-source too, but it's playing a different game. It doesn't just want to store your vectors — it wants to be the backbone of your entire AI pipeline.
Why it stands out. Two reasons. First, hybrid search, which Weaviate shipped back in late 2022, ages before most of the field caught on. Its implementation is genuinely mature — proper keyword scoring fused with vector results — so if blending semantic and exact-match retrieval is core to your product, this is the most grown-up native option out there. Second, it'll do your embeddings for you: send raw text, and Weaviate vectorizes it on the way in using OpenAI, Cohere, Hugging Face, whatever. Fewer moving parts in your pipeline, which is a real quality-of-life win.
Where it gets heavy. Those built-in vectorizers aren't free — they call the same embedding APIs you'd call yourself, so you're paying that latency and cost, just somewhere less visible. The GraphQL API is a genuine learning curve if your brain is wired for SQL or plain REST. And the Java runtime is hungry when you self-host; operational complexity climbs as you pile on modules and multi-tenancy.
Use it if: native hybrid search is a hard requirement, or you genuinely want the database to handle vectorization so your pipeline has fewer parts to break.
Milvus: bring this one out when things get enormous
Milvus is the most-starred open-source option on GitHub, backed by Zilliz (whose managed Zilliz Cloud is the souped-up enterprise version). It exists for one reason: scale that makes everything else fall over.
Why it earns its place. Nothing else here touches its distributed architecture when you're genuinely big. Heading past a billion vectors? Need GPU-accelerated indexing? This is the tool built for that exact day. At the 100M+ range it's a serious candidate, full stop.
Why you shouldn't reach for it casually. It's a lot of machine. The operational complexity outpaces Qdrant's for normal use cases — budget real engineering time for the Kubernetes wrangling, and expect your team to climb a learning curve. There's also a known performance gotcha around output fields that can bite in RAG pipelines. If you're under a few tens of millions of vectors, Milvus is almost certainly more database than your problem deserves.
Use it if: you're truly heading into 100M–1B+ territory or need distributed GPU indexing, and you've got the ops capacity to run it.
A quick word on the ones I skipped
ChromaDB earns an honorable mention — it runs right inside your Python process with zero config and is a joy for prototyping. It just doesn't bring the production tooling (high availability, snapshots, real monitoring) the big five do, so think of it as where you start, not where you stay. Faiss (a library, not a database), LanceDB (multi-modal first), Vespa, and the cloud-native managed options like Vertex Vector round out the wider field — but the five above are the ones people actually argue about in production Slack channels.
The hybrid-search thing I keep promising to explain
Here it is, because it quietly decides more choices than people expect. Pure vector search is wonderful right up until someone searches for an exact SKU, a person's name, or "v2.3.1" — and your beautiful semantic embeddings return something thematically adjacent but useless. Real systems need both: the fuzzy semantic match and the exact keyword hit, in the same query.
Weaviate and Qdrant ship this natively. Pinecone bolted it on. pgvector makes you assemble it yourself by hand. If you're building agent memory or RAG over genuinely varied content, treat hybrid search as non-negotiable and let it tilt your decision. It's not a nice-to-have anymore; it's table stakes wearing a trench coat pretending to be a differentiator.
So, what do you actually pick?
If you take one thing from all of this:
You're on Postgres and under ~50M vectors? Use pgvector and go build something. Stop researching.
You never want to see a config file? Pinecone, and make peace with the lock-in.
Self-hosting and you care about speed or filtering? Qdrant.
Hybrid search is the heart of the product? Weaviate.
Staring down hundreds of millions of vectors? Milvus.
And the meta-lesson under all of it: the benchmarks are tie-breakers, not deciders. The database you prototype with probably isn't the one you'll ship, so optimize for the one that's easiest to reason about today and least painful to leave tomorrow. For most teams, honestly, that's pgvector right up until something specific drags them off it — and "something specific" tends to arrive a lot later than the breathless blog posts would have you believe.
One fair warning on the numbers in here: the benchmark figures floating around the industry come from wildly different test setups — different vector dimensions, different hardware, different recall targets, and quite often run by the vendor whose database happens to win. Treat all of it as directionally true rather than gospel, and test against your own data at your own scale before you bet the product on it.