A team asked which vector database was fastest. The better question was why they needed a separate vector database at all. Their corpus had 400,000 chunks, every query was tenant-filtered, permissions lived in Postgres, and nobody measured recall.
Another team had 600 million vectors, strict p99, heavy metadata filtering, and a retrieval team with its own SLO. Keeping that inside the OLTP database would have made both systems worse.
Vector database choice is an ownership decision before it is a benchmark decision.
The framework: where does product truth live?
If Postgres owns documents, permissions, billing state, and lifecycle, pgvector has a strong starting advantage because retrieval stays close to product truth. If retrieval has its own scaling, quality, and operations team, a dedicated vector database becomes easier to justify.
pgvector
pgvector is strongest when relational rules matter and the corpus is modest enough for Postgres operations. It gives one backup path, one transaction boundary, one permission model, and SQL-native debugging. The risk is making OLTP and retrieval fight for the same resources after vector search becomes a serving system.
Pinecone
Pinecone is attractive when the team wants a managed vector service, metadata filtering, namespaces, and less index-operation ownership. The tradeoff is that product truth must be synchronized into a separate system, and cost should be measured per successful answer, not per stored vector.
Qdrant
Qdrant is a strong option for teams that want a dedicated vector engine with payload filtering, quantization options, and operational control. It fits teams willing to own a serving system and its sync path from the source database.
Weaviate
Weaviate is compelling when hybrid search and object-style schemas are central to the product. It can be a good fit for teams that want vector and lexical search behavior in one retrieval layer. The same sync and permission questions still apply.
The decision checklist
- What recall target does the product require?
- How selective are metadata filters?
- Where do permissions and deletes originate?
- Can retrieval scale independently from OLTP?
- Who owns index rebuilds and quality regressions?
- What is the rollback path if retrieval quality drops?
- Can the team export and migrate vectors without rewriting the product?
The pragmatic default
Start with pgvector when Postgres already owns the data and the workload is still learning its quality bar. Move to a dedicated vector database when retrieval has become its own product surface with independent scale, cost, and SLOs. The mistake is picking the tool before measuring the workload.
The runbook I want before this reaches production
Before I trust this design, I want a small runbook that names the failure mode, the owner, and the rollback path. Vector systems fail in ways that look like product quality problems: missing evidence, stale evidence, wrong-tenant evidence, high p99, or answers that cite weak chunks. If the team cannot tell which one happened, the system is not observable enough.
- Define a golden query set with real permissions and expected source documents.
- Track recall, result count, p95, p99, and cost by query class.
- Keep a rollback path for index, embedding model, chunking, and metadata changes.
- Test deleted, restricted, fresh, and re-embedded documents as canaries.
- Review the dashboard after every bulk import, re-embedding job, and index rebuild.
The practical standard is simple: a retrieval change should be measurable before it ships, visible while it runs, and reversible when quality drops.