Vector databases compared: Pinecone vs Weaviate vs pgvector

What a vector database does, in one paragraph

When you build a RAG system or semantic search, your content gets converted into vectors, long lists of numbers that capture meaning. To answer a question, you convert the question the same way and find the stored vectors closest to it. A vector database is the system that stores those vectors and finds the nearest ones fast, even across millions of them.

That is the whole job. Everything else, hosting model, metadata filtering, hybrid search, is a feature on top of fast nearest-neighbour search. Keeping that in mind stops you from being dazzled by feature lists that do not matter for your use case.

pgvector: the pragmatic default

pgvector is an extension that adds vector search to Postgres, the database you very likely already run. That single fact makes it the right starting point for a large majority of teams, and it is the one we reach for most.

Why it wins for so many:

• No new system to operate. Your vectors live next to your relational data, with one backup, one security model, one thing to monitor.
• Filtering is trivial because you have full SQL. Combining a similarity search with normal WHERE conditions just works.
• It scales comfortably into the millions of vectors, which is more than most enterprise knowledge bases ever reach.
• It is free and open, with no per-query pricing surprises.

Pinecone: managed scale with minimal ops

Pinecone is a fully managed vector database built to do one thing extremely well at very large scale. You do not run it; you call it. For teams without infrastructure depth, or with hundreds of millions of vectors and demanding latency targets, that trade is attractive.

Where Pinecone earns its place:

• Very large scale and high query volume where tuning your own index becomes a real engineering job.
• Teams that would rather pay to never think about sharding, replication, or index maintenance.
• Fast time-to-production when you have no appetite to operate infrastructure.

Weaviate: hybrid search and control

Weaviate is an open-source vector database (with a managed cloud option) that leans into hybrid search, combining semantic similarity with keyword matching, and gives you more control over how retrieval works. It sits between the do-it-yourself simplicity of pgvector and the hands-off managed model of Pinecone.

Consider Weaviate when:

• Hybrid search (semantic plus keyword) is central to your quality, and you want it built in.
• You want to self-host for data-residency or cost reasons but still want vector-native features.
• You expect to grow into more advanced retrieval and want room to configure it.

The decision, made simple

It is easy to lose a week comparing benchmarks. Do not. For the overwhelming majority of enterprise projects, the decision is far simpler than the vendor pages suggest, and starting in the right place saves you a migration later.

• Already on Postgres and under tens of millions of vectors? Use pgvector. This is most teams.
• Hundreds of millions of vectors, demanding latency, thin ops team? Pinecone.
• Hybrid search is core, or you must self-host with vector-native features? Weaviate.
• Unsure? Start with pgvector. Moving later is cheap; over-building now is not.

What actually determines quality (hint: not the database)

Here is the part vendor comparisons bury: the vector database is rarely what makes a RAG system good or bad. Teams obsess over picking the perfect store and then ship mediocre results because the parts that actually matter were neglected.

Spend your attention here instead:

• Chunking: how you split documents has more impact on answer quality than the database choice.
• Embeddings: the model that turns text into vectors sets your ceiling for retrieval quality.
• Re-ranking: a re-ranking step after retrieval fixes more problems than switching databases ever will.
• Metadata and filtering: good metadata is the difference between relevant and almost-relevant results.

Avoiding the migration trap

The most expensive vector-database decision is the one made for a scale you do not have yet. We regularly see teams start on a heavyweight managed platform for a knowledge base of a few hundred thousand vectors, paying in money and complexity for headroom they will not use for years.

Start with the simplest thing that fits your real numbers, instrument it so you can see latency and recall, and let the data tell you when to move. A migration triggered by measured need is a good day. A migration you architected for on day one, before any users existed, usually was not necessary.