WHAT A VECTOR STORE ACTUALLY DOES
A vector store holds high-dimensional numerical representations of content — embeddings — and answers the question "what's most similar to this?" efficiently. When you embed a user's query and a corpus of documents, a vector store lets you find the top-k most semantically similar documents in milliseconds, even across millions of items. This is the retrieval half of Retrieval-Augmented Generation.
The core operation is approximate nearest neighbour search (ANN). Exact nearest neighbour at scale is prohibitively slow; ANN algorithms like HNSW and IVFFlat trade a small amount of accuracy for massive speed gains. Most vector stores implement one or more of these indexes, and the implementation quality determines performance characteristics at scale.
Every vector store also needs to handle filtering — you usually want "find the most similar documents to this query from this user's account." This combination of vector similarity search with metadata filtering is where the databases diverge significantly in both API design and performance.
WHEN PGVECTOR IS ENOUGH
pgvector is a PostgreSQL extension that adds vector types and ANN indexes to your existing Postgres database. If you're already running Postgres — which most applications are — adding pgvector costs nothing operationally. You keep your existing schema, your existing backup strategy, your existing connection pooling. Your vectors live in the same transaction boundary as your application data.
The performance ceiling is real but higher than most people assume. pgvector handles up to roughly 5 million vectors with sub-100ms query latency on reasonable hardware, using the HNSW index introduced in version 0.5.0. For the vast majority of first-generation RAG applications, this is plenty. A knowledge base with 100,000 chunked documents is well within pgvector's sweet spot.
The development experience advantage is also significant. You can query vectors alongside relational data in a single SQL statement. Metadata filtering is just a WHERE clause. Joins work. Transactions work. You don't need to learn a new query language or manage a new infrastructure component. For teams who want to move fast on the application layer, reducing the operational surface area is genuinely valuable.
WHEN YOU NEED A DEDICATED VECTOR DATABASE
Pinecone becomes the right choice when you're operating at a scale where pgvector's performance ceiling becomes a constraint — typically above 5–10 million vectors with high query throughput requirements. Pinecone's serverless architecture handles burst traffic gracefully, and its managed infrastructure removes the need for you to tune indexes or provision hardware as your dataset grows.
Weaviate is the better choice when hybrid search — combining semantic similarity with keyword relevance — is central to your use case. Its BM25 + vector hybrid search is natively supported and well-optimised, while adding keyword search to pgvector requires composing multiple query strategies manually.
Qdrant is worth evaluating when you need the lowest possible latency on complex filtered queries. Its implementation of filtered ANN search is consistently faster than Pinecone's on benchmarks involving dense metadata filtering. If your RAG system serves real-time user-facing features where P99 latency is a product requirement, Qdrant's architecture is worth the operational overhead.
OUR DEFAULT RECOMMENDATION
Start with pgvector. The reasons to start elsewhere — scale, hybrid search, extreme latency requirements — rarely apply to a first production RAG system. You can always migrate later, and the shape of the problem usually clarifies once you have real traffic data.
When you do migrate, the cost is manageable. Embeddings are stateless — you can regenerate them from your source content. The migration is essentially: re-embed your corpus, import into the new store, update your query code. It's a few days of engineering work, not a multi-month project.
The teams we've seen get into trouble are the ones who optimised vector infrastructure prematurely — spending two sprints configuring Pinecone indexes before their application had any users. The operational complexity is real, and the payoff doesn't materialise until you've validated that the product is worth scaling. Pgvector lets you defer that complexity until you actually need to confront it.