Most teams pick a vector database the same way. Someone reads a benchmark, someone else has used Pinecone before, and the decision is made in a planning meeting before anyone has looked at the data. Six months later the retrieval quality is mediocre, the bill is higher than expected, or the team is running a second database it never really needed.
This guide compares pgvector, Pinecone and Weaviate for production RAG and semantic search. It covers when Postgres is enough, how the three differ on filtering and hybrid search, what drives cost, and when it is worth bringing in vector database consultants for a short store-selection engagement.
When you need a dedicated vector database (and when Postgres is enough)
If your application already runs on Postgres and your corpus is in the low millions of chunks or below, start with pgvector. You keep one database, one backup story and one permission model. Your embeddings sit next to the rows they describe, so a query like “documents this user is allowed to see, from the last 90 days, most similar to this question” is a single SQL statement with a normal WHERE clause.
A dedicated store starts to earn its place when one of three things is true. The index has grown large enough that it competes with your transactional workload for memory. Query volume is high and spiky, and you would rather not size Postgres for the peak. Or the retrieval team needs to move faster than your database change process allows.
None of those are about vectors as such. They are about operations and ownership, which is why the choice is less technical than the benchmarks make it look.
pgvector, Pinecone and Weaviate compared
pgvector is a Postgres extension. It supports exact search and approximate indexes (HNSW and IVFFlat), and it runs anywhere Postgres runs, including the managed services most teams already pay for. Filtering is plain SQL, which is its biggest strength. The trade-off is that tuning is your job: index parameters, memory, vacuum behaviour and how the planner combines a filter with an approximate index all need attention once the table gets big.
Pinecone is a fully managed service. You do not run servers or tune indexes, and scaling is handled for you. Metadata filtering is built in, and it supports sparse plus dense vectors for hybrid retrieval. You give up some control and you add a second system that holds a copy of your data, so access rules and deletions have to be kept in sync with your source of truth.
Weaviate is open source and can be self-hosted or used as a managed cloud service. Hybrid search, combining BM25 keyword scoring with vector similarity, is a first-class feature with a single weighting parameter. It also has modules that can call embedding models for you. Self-hosting gives you control but means someone on your team owns another stateful service.
Qdrant and Chroma come up in the same conversations, and the same questions apply to them: who operates it, how filtering behaves under load, and how hybrid search is done.
Hybrid search and re-ranking
Pure vector search is good at meaning and bad at exact strings. Ask it for a product code, an error message or a clause number and it will often return something that sounds similar instead of the thing itself. Keyword search has the opposite problem. Combining the two, then re-ranking the top results with a cross-encoder or a small model, fixes a large share of the “the answer was in the documents but the system did not find it” complaints we see in RAG projects.
All three stores can support this, in different ways. Weaviate and Pinecone offer hybrid queries directly. With pgvector you usually combine Postgres full-text search and vector similarity yourself, often with reciprocal rank fusion, which is more work but also more transparent. We wrote about this failure pattern in RAG in production: what breaks.
Business rules belong in the ranking too. In our e-commerce search case study, availability and margin had to sit alongside semantic relevance, and conversion from search rose 27% once they did. That kind of logic is easier when your filters and your vectors live close together.
Cost drivers to model before you pick
Price pages are hard to compare directly, so model your own numbers instead. Four inputs matter most.
Embedding volume is the first. How many chunks do you have today, how fast does the corpus grow, and how often do documents change? Re-embedding after a model upgrade can cost more than storage for a year.
Index size comes next, driven by chunk count and vector dimensions. Higher-dimension embeddings take more memory, and approximate indexes usually want to sit in memory to stay fast.
Then query load: average queries per second, the peak, and how many results each query pulls before re-ranking. Finally, the people cost. A self-hosted store is cheaper on the invoice and more expensive in engineering hours. A managed store is the reverse.
Migration risk: switching stores later
Switching vector databases is less painful than switching your main database, but it is not free. Each store has its own filter syntax, its own hybrid search behaviour and its own score scale, so retrieval quality can change even when the embeddings are identical.
The way to keep the door open is boring. Put retrieval behind one internal interface, keep your raw text and metadata in your primary database, and keep an evaluation set of real questions with known good answers. If you can re-run that set against a new store in an afternoon, migration becomes a measured decision instead of a leap.
Signs you should bring in vector database consultants
You probably do not need outside help to stand up a prototype. It is worth a conversation when retrieval quality has stalled and nobody can say why, when latency or cost climbed as the index grew, or when a regulated workload needs permission-aware retrieval that you have to be able to explain to an auditor. Another common trigger is a team about to commit to a store for a multi-year product without having tested it on its own data.
What a short store-selection engagement looks like
A store-selection engagement starts with your data and your questions, not a vendor list. We sample the corpus, agree on a set of real queries with expected answers, and run them against the realistic candidates with your filters and access rules in place. You get recall and latency numbers from your own workload, a cost model built from your volumes, and a recommendation on the store, the embedding pipeline and the hybrid search setup.
From there, the same team can build the pipeline and instrument it so retrieval quality is tracked after launch. That work is described on our RAG development and AI search and retrieval pages.
Talk to us about your retrieval stack
If you are choosing between pgvector, Pinecone and Weaviate, or living with a choice that is not working, book a free discovery call. Bring a sample of your data and a few questions your users actually ask, and we will tell you honestly whether you need a new store at all.
