Vector Databases Compared: Pinecone, Weaviate, pgvector, Qdrant

What you actually need to know

• Vector databases store high-dimensional embeddings and retrieve the nearest neighbors by cosine or dot product similarity. They are the retrieval layer in most RAG pipelines.
• The choice between these four is mostly about your operational model: managed cloud, self-hosted, or Postgres extension.
• pgvector is the right starting point if you are already on Postgres and your vector count is under twenty million.
• Pinecone wins on simplicity when you want zero infrastructure and your team cannot afford to maintain another service.
• Qdrant is the best option when you need self-hosting, strong metadata filtering, or infrastructure control for compliance.

The core argument

Most teams spend too long deciding between vector databases and not enough time tuning the embedding model and retrieval logic. The database is not the bottleneck. The bottleneck is usually the quality of the chunks you are indexing and the precision of the filters you apply at query time.

That said, the choice matters at scale and it matters operationally. The team that picks Pinecone because it is easiest to get started with will eventually hit a pricing wall. The team that picks pgvector because it avoids a new service will eventually hit a performance wall if their vector count climbs. Neither wall is insurmountable, but both require migration work.

My default recommendation for a new project: start with pgvector if you are on Postgres. It takes about an hour to get running, you do not need to manage another service, and you can migrate to Qdrant or Pinecone later if query latency becomes a problem. The index format is standardized enough that the migration is not as painful as it sounds.

The argument for Pinecone is speed of execution, not speed of queries. If your team has two weeks to ship a working RAG feature, Pinecone's serverless tier gets you there without any infrastructure decisions. You pay for that convenience later when the bill scales with usage and you have no control over the pricing model.

How each database handles the hard parts

Filtering alongside similarity

This is where the databases diverge most visibly. Pure similarity search finds the nearest vectors. Filtered similarity search finds the nearest vectors within a subset defined by metadata. If your use case is "find documents similar to this query, but only for this customer's tenant," filtering is not optional.

Qdrant was designed with filtering as a first-class concern. Its payload indexing handles high-cardinality filters without the performance degradation you see in other systems. Weaviate has strong filtering too. pgvector's WHERE clause filtering works but can be slow on large tables without careful index design. Pinecone added metadata filtering and it is functional, but the filtering language is simpler than Qdrant's.

Hybrid search

Hybrid search combines keyword matching with semantic similarity in one query. For most real-world retrieval, hybrid outperforms pure vector search because some queries are better served by exact keyword matching and some by semantic similarity. You rarely know in advance which type any given user query will be.

Weaviate has the most mature hybrid search implementation. It runs BM25 and vector search in parallel and merges the results with a configurable alpha parameter. pgvector requires running two queries and merging in application code, which adds latency and complexity. Pinecone added sparse-dense hybrid and it works, but the setup is more manual.

Multi-tenancy

For B2B SaaS, every customer's vectors need to be isolated. The patterns differ by database. Pinecone uses namespaces. Qdrant uses collections or payload filtering. pgvector uses row-level security on the Postgres table, which is familiar to any Postgres developer. Weaviate uses multi-tenancy at the class level.

None of these is obviously better. The question is which model matches your existing tenant isolation pattern.

How much does it cost

Prices are approximate 2026 figures from public pricing pages and my own client engagements. The pgvector line is deceptive because you are paying for the Postgres instance, not the extension itself. At scale, a well-configured Postgres instance serving vector queries is often cheaper than a dedicated vector cloud service.

What to look for when evaluating

• HNSW indexing support. Flat indexes do exact search and are slow at scale. HNSW is the standard approximate nearest neighbor algorithm that keeps query time manageable.
• Metadata filtering performance on your actual filter cardinality. Test with real data, not synthetic data.
• Hybrid search native support if your use case involves documents where users type specific keywords.
• Client library quality in your language. The Python clients for all four are decent. The TypeScript clients vary.
• Multi-tenancy isolation model that matches how you partition customers.
• Update and delete performance if your vector corpus changes frequently. Some indexes degrade on high churn.

Expert opinion

pgvector handles ninety percent of the projects I encounter. The teams that go straight to Pinecone usually do it because they are afraid of Postgres operational complexity, and then spend three months figuring out that Pinecone's pricing model does not fit their usage pattern. Start simple. Migrate when you have real numbers to justify the move.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A client came to me with a half-built document search feature that used Pinecone on the free tier. The prototype worked fine. When they moved to production with a real customer corpus, the free tier limit hit in week two and the paid tier was coming in at four hundred dollars a month for their query volume. The team had not budgeted for it and the number surprised everyone.

We migrated to pgvector on their existing Supabase instance over three days. The query performance was within acceptable range for their use case, the filtering logic was cleaner using SQL, and the monthly cost dropped to zero incremental cost on top of their existing database hosting. The migration was not painless but it was worth it. We lost one weekend, saved significant monthly spend, and the retrieval quality was identical because we kept the same embedding model.

The lesson was not that Pinecone is bad. The lesson was that the database choice needs to include a cost projection at production scale from day one. For more on the retrieval architecture side, see RAG retrieval augmented generation for SaaS and building an AI powered search that actually works.

Common mistakes

1. Picking a database because of a demo without testing on real data at real scale.
2. Starting with Pinecone's free tier and then being surprised by the production pricing model.
3. Using flat exact search indexes instead of HNSW, then wondering why queries are slow at a hundred thousand vectors.
4. Not chunking documents before indexing. Embedding entire pages produces poor retrieval. Chunk at the paragraph or section level.
5. Switching embedding models mid-production without re-indexing all vectors. The old and new vectors are incomparable.
6. Ignoring the multi-tenancy isolation model until the first enterprise customer asks about data separation.
7. Building semantic search without testing hybrid search. For document retrieval, hybrid almost always outperforms pure vector search.
8. Not setting a dimension limit on the embedding model upfront, then realizing your index is sized for 1536 dimensions when your new model produces 3072.

A 30-day plan

1. Week one. Pick pgvector if you are on Postgres, Qdrant if you need self-hosted with strong filtering, Pinecone if you need zero infrastructure fast. Get a small index running with real data from your corpus.
2. Week two. Test retrieval quality with your actual query patterns. Measure precision at k=5 and k=10. Adjust chunking and embedding model before tuning the database.
3. Week three. Add metadata filtering for tenant isolation. Test filter performance with a representative number of tenants and documents per tenant.
4. Week four. Run a cost projection at ten times your current data volume. If the number is uncomfortable, model the migration to pgvector or Qdrant now, before the data grows.

For the broader retrieval and AI integration pattern, see building production grade AI features without an ML team and AI evals how to test your AI features like software.