Vector store comparisons usually turn into benchmark drag races — who does the most queries per second at the lowest latency. That framing misleads most teams, because for most teams raw QPS is not the binding constraint. The real decision is about fit: how much data you have, how much infrastructure you want to operate, and whether your vectors need to sit next to your relational data. Here's a decision framework across the three common choices — Postgres/pgvector, Pinecone, and Weaviate — that starts from those questions instead of a throughput chart.
The three options in one line each
- pgvector — a Postgres extension that adds vector columns and ANN indexing to a database you probably already run. Your vectors live in Postgres, next to your relational data.
- Pinecone — a fully managed, vector-native database. You don't operate anything; you call an API. Built to scale vector search with minimal ops.
- Weaviate — a feature-rich vector database (hybrid search, modules, flexible deployment) available self-hosted or managed. More capability, more surface area.
None is "best." They're optimized for different constraints.
The questions that actually decide it
How much data do you have? This is the first filter. Under roughly ten million vectors, a well-tuned Postgres with pgvector handles the workload comfortably. As you climb into hundreds of millions or billions, purpose-built systems that were designed to shard and distribute the index earn their keep. Be honest about your actual scale, not your aspirational one — most teams have far fewer vectors than they assume, and provisioning for a billion when you have a million is buying complexity you won't use.
How much do your vectors need to live with your relational data? This is the underrated question. If your queries constantly filter and join vectors against relational data — scope by tenant, filter by date, join to a documents table — then keeping vectors in Postgres is a large advantage. You do it in one SQL query, transactionally, with no data sync between systems. Split them into a separate vector database and you're either duplicating metadata or making two round-trips and reconciling. This coupling is exactly why Kognita stores vectors in Postgres (Neon) — the relational integration is worth more than marginal ANN throughput for a knowledge-base workload.
How much infrastructure do you want to operate? A fully managed service (Pinecone, or managed Weaviate) means no index tuning, no scaling, no ops — at a price and with your data in their system. Self-hosting (pgvector in your own Postgres, self-hosted Weaviate) means control and often lower cost, but you own the operations. Small teams usually value fewer systems and less ops; that pushes toward "use the Postgres you already run" or "pay someone to run it."
Do you need specific advanced features out of the box? Built-in hybrid fusion, reranking, multi-vector/late-interaction retrieval, vectorizer modules — some vector-native databases ship these ready-made. With pgvector you assemble them yourself (or use a managed RAG layer that does). If those features are core to your product and you don't want to build them, that's a point for a feature-rich vector database.
The decision matrix
| pgvector | Pinecone | Weaviate | |
|---|---|---|---|
| Scale sweet spot | ≤ ~10M vectors | Very large, elastic | Large, flexible |
| Ops burden | You run Postgres | Fully managed | Self-host or managed |
| Vectors next to relational data | Native | Separate system | Separate system |
| Built-in advanced retrieval | Assemble yourself | Managed features | Rich, built-in |
| Best when | You value few systems + data coupling | You want zero ops at scale | You want built-in features/flexibility |
The recommendation for most teams
Start with pgvector if you already run Postgres and have millions (not billions) of vectors — especially if you filter or join vectors against relational data. It's not a compromise at that scale; it's the sensible default, and it removes an entire system from your architecture.
Reach for Pinecone when you want vector search to just work at large scale with zero operational involvement and you're happy to run it as a separate managed system.
Reach for Weaviate when you want a feature-rich vector database with hybrid search and modules built in, and you want flexibility over deployment.
The meta-point: don't pick a vector store from a QPS benchmark. Pick it from your scale, your ops appetite, and how coupled your vectors are to the rest of your data. For a large share of real applications, those questions point back to the database you're already running — and the fanciest distributed vector engine is solving a scale problem you don't have yet.