Start from ops constraints, not benchmark charts
Vector DB choice is really a question about team skills, existing data stores, and query patterns. A five-million-chunk corpus with heavy metadata filtering behaves differently from a fifty-thousand-chunk internal wiki.
Indian startups on PostgreSQL often begin with pgvector to avoid new infra. Enterprises with hybrid search needs and dedicated search SREs may prefer OpenSearch or managed Pinecone. There is no universal winner — only fit to your hiring and cloud contract.
Features that matter in production
Filter by tenant, region, and document version at query time — multi-outlet restaurants and multi-tenant SaaS need this day one. Backup/restore, reindex pipelines, and delete-by-source when a document is retracted.
Latency SLOs: p95 query under your UX threshold including embedding step. Cost model: storage, query units, and re-embedding after model upgrades. Test failure modes when the index is rebuilding — degrade to keyword search or queue requests.
Migration and future-proofing
Abstract vector operations behind a repository interface so you can migrate from pgvector to a managed service when scale demands — without rewriting RAG orchestration. Version embeddings; plan reindex jobs when you change dimensions or model family.
Sabrixa selects stores per engagement — often Postgres or OpenSearch on AWS for Indian clients — and documents the trade-off memo so your team understands why, not just which logo appeared on the architecture slide.