TL;DR — Start on pgvector. Move to Qdrant or Pinecone only when you have a real performance, scale or filtering problem that pgvector cannot solve. Each tool wins in a different zone; the wrong default costs you operations time or vendor lock-in.
What we evaluate them on
- Operational simplicity — what does it take to run in production?
- Query latency at scale — p50 and p95 with 1M, 10M, 100M embeddings
- Filtering — can it efficiently combine vector similarity with metadata predicates?
- Cost — per million vectors per month at typical query loads
- Lock-in — how hard is it to leave?
pgvector
A Postgres extension that adds vector similarity search. HNSW and IVFFlat indexes. Lives inside your existing database — same backups, same observability, same access patterns.
Wins: simplest operations, cheapest at small/mid scale, transactional consistency with the rest of your data, no new system to learn. Loses: performance degrades past ~5–10M vectors, filter+vector queries can be slow if predicates aren’t selective, HNSW index rebuilds are expensive.
Qdrant
Open-source vector database written in Rust. Self-hostable or managed cloud. Strong filtering, payloads with secondary indexes, dynamic schema.
Wins: excellent filtering performance, scales well past 100M vectors, low latency at p95, no vendor lock if you self-host. Loses: separate system to operate, no transactional consistency with primary database, smaller ecosystem than Pinecone.
Pinecone
Fully managed vector database. No infrastructure to run. Serverless and pod-based plans. Strong product velocity and SDK quality.
Wins: least operational work, fastest path from prototype to production, mature SDKs across languages. Loses: highest cost per vector at scale, full vendor lock-in, less control over index tuning than self-hosted options.
Decision matrix
| Situation | Pick |
|---|---|
| < 5M vectors, already on Postgres | pgvector |
| 5M–100M vectors, self-host comfortable | Qdrant |
| Want managed, willing to pay, no ops bandwidth | Pinecone |
| Heavy filter+vector queries | Qdrant |
| Need transactional consistency with primary data | pgvector |
The migration path
Migrations between vector databases are easier than between relational databases — the data model is roughly “id + vector + payload,” and re-indexing is straightforward if you keep the source embeddings. Plan the abstraction layer in your code (one repository class hiding the vector backend) and a migration is a weekend, not a quarter.
Frequently asked questions
When should I move off pgvector?
When your embedding count crosses ~5–10 million and query latency at p95 stops fitting your SLO, or when you need filters that pgvector indexes do not accelerate well. Until then, pgvector is the cheapest path with the simplest operations.
Is Pinecone worth the cost?
Yes for teams that want a managed service and do not want to operate a search system. No for teams comfortable running Qdrant or Weaviate — the per-vector cost adds up fast at scale.
Working on something similar?
T-Square is an independent software engineering studio. We architect, build and operate production-grade systems for learning, AI and custom software products. Talk to a senior engineer if you’d like a second opinion on your architecture or roadmap.