There's a moment in almost every RAG project where someone asks the question that decides your next two years of ops work: "Do we actually need a vector database, or can Postgres just do this?"
It's a better question than it sounds, because the honest answer isn't "use Pinecone" or "use Postgres." It's "it depends on numbers you probably haven't measured yet": how many vectors, how aggressively you filter, how much you care about the absolute ceiling of queries per second. Most teams pick based on a blog post's leaderboard and then spend a quarter discovering that the leaderboard measured a workload nothing like theirs.
So let's not do that. Let's look at what these four (pgvector, Qdrant, Pinecone, and Weaviate) are actually doing under the hood when you ask them to find the closest vectors, why their filtering stories are wildly different, and where each one falls off a cliff. By the end you'll be able to answer the Postgres question for your workload, not a benchmark's.
They're all approximating the same thing
First, the thing that unites all four: none of them are really finding the nearest vectors. They're finding probably the nearest vectors, fast.
