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, with 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, with the 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 suddenly 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.
Top comments (9)
I agree with you—there's no need to bring out the heavy artillery for lightweight operations. That said, I’d add MyScaleDB (a ClickHouse fork) for those who do need that heavy artillery and started out with pgvector; they can preserve some of their existing code since MyScaleDB speaks SQL just like you and me 😁, and the engine is vastly more powerful than PostgreSQL's—plus, you get access to ClickHouse's entire toolkit.
That's a solid addition, thanks. I didn't cover MyScaleDB in this pass and the "you get ClickHouse's toolkit for free" angle is genuinely underrated as a migration path. Going from pgvector to something that still speaks SQL removes most of the rewrite pain that usually kills these migrations before they start. I'll dig into it for a follow-up, especially how it handles filtered search at scale compared to pure OLTP engines. Appreciate the pointer.
Glad it was useful! I think that's really where MyScaleDB shines: it isn't just a vector database, it's an analytical engine with native vector search. So if a project outgrows PostgreSQL because of scale or hybrid analytical workloads—not just because of embeddings—you can migrate without giving up SQL or rebuilding your application layer.
I'd also be curious to see your take on filtered vector search. In my experience, that's where combining ClickHouse's columnar execution with vector search starts to show its strengths compared to traditional OLTP-first architectures.
"Pick based on the infrastructure you already run" is the line I wish more RAG content led with — the pgvector gravity is real and underrated. One trade-off I'd add to the cheat sheet, because it's where I've watched teams actually hit a wall: filtered vector search. The moment your query is "nearest neighbors where tenant_id = X and status = active", the clean benchmark numbers stop applying. Pre-filtering can blow up latency and post-filtering can wreck recall@k, and how each engine handles that (pgvector leaning on the planner, Qdrant's payload index, etc.) matters far more at real scale than the 3ms headline difference.
The other quiet cost nobody budgets for: the lock-in isn't the database, it's the embedding model. The day you upgrade embeddings you re-embed and re-index the entire corpus regardless of vendor, and that backfill is usually the expensive part. Did you find any of these five materially easier to live-reindex behind a running app without a read-downtime window?
This is the comment I wish I'd had before publishing. You're right that filtered search is where the clean benchmarks fall apart, and I probably should have given it more than a paragraph. Pre-filter versus post-filter versus in-traversal filtering is a real fork in the road at production scale, not a footnote.
On live re-indexing without downtime, honestly, I didn't test this hands-on so I don't want to overstate it. From what I've read, Qdrant's collection aliasing (build a new collection, swap the alias, no client-facing downtime) and Weaviate's similar approach of standing up a new class and cutting over both seem to handle this more gracefully than pgvector, where a full HNSW rebuild on a live table tends to mean either a maintenance window or careful use of a shadow table plus a swap. But I'd trust someone who's actually run that migration over my read of the docs. Have you done one of those cutovers yourself?
And agreed on the embedding lock-in point, that's the real cost center and it's underdiscussed. Might be worth its own piece.
Good comparison, and the "pick based on infrastructure you already run" advice is spot-on. One thing the article doesn't touch on: what if you don't have infrastructure? Embedded systems, robotics, mobile apps, edge devices â none of them are running Postgres or Kubernetes. The vector DB options for that space are surprisingly thin.
Qdrant being Rust-based is the closest fit for on-device deployments, but it wasn't designed for embedded â you still need a server process, separate from your application. For agentic systems running on robots or drones, the database has to live inside the same process, survive power cycles, and handle multimodal data (not just vectors but also time-series sensor streams, images, structured metadata) without a network call.
This is one of the gaps moteDB is trying to fill â an embedded multimodal database in Rust that runs in-process, supports vectors + structured data + blobs in a single ACID store. Not a replacement for pgvector or Qdrant at scale, but for the class of problems where "just run Postgres" isn't an option because there's no server to run it on. Curious if you came across any embedded vector DB options during your research that I missed.
This is a genuinely useful gap to flag, and you're right that I didn't touch it. Everything in the article assumes you have a server to run something on, which is a real blind spot when the whole point of an edge or robotics deployment is that you often don't.
I didn't come across a strong embedded, in-process, multimodal option in my research, which is partly why I didn't cover it, I didn't want to write about a category I hadn't actually found good examples in. Qdrant being the "closest fit" while still needing a separate server process is a good way to put it; that's a real architectural mismatch for anything that needs to survive a power cycle standalone.
The in-process-plus-ACID-plus-multimodal combination you're describing for moteDB sounds like it's solving a genuinely different problem than pgvector or Qdrant, less "which vector database" and more "how do I get vector search inside an application that has no infrastructure around it at all." Worth being upfront that it's a different category rather than a competitor to the five here. I'll look into it, would be a good angle for a dedicated edge/embedded piece if you're open to it being covered in more depth.
Useful breakdown. The thing I'd add for anyone choosing in 2026: the database is rarely where the project lives or dies, the retrieval quality is. pgvector vs Pinecone vs Qdrant matters at scale, but most teams lose more to bad chunking and irrelevant context than to the engine. Pick the one that fits your ops reality, then spend the saved energy on what you feed it. The vector store is a component; the context strategy is the product.
Fair, and it's a needed corrective to an article that's entirely about the engine. The database choice is the part people obsess over because it's a discrete decision with a comparison table, benchmarks, a clear "pick one." Chunking strategy and context quality are messier, there's no leaderboard for "did I chunk this well," so it gets less attention even though it's usually where retrieval quality actually breaks.
I'd push back slightly on "rarely where the project lives or dies" though. I think it's more that the two failures look different: a bad database choice shows up as a scaling or ops problem you feel later, a bad retrieval strategy shows up as silently bad answers you might not notice until a user complains. Both kill projects, just on different timelines. But the core point stands, get the engine right once and move on, then spend the real energy on what you're feeding it.