TL;DR: pgvector, MongoDB Atlas Vector Search, and Snowflake Cortex are operationally correct when vector queries are tightly coupled to filtered metadata, your dataset stays under ~100 million embeddings, and reducing complexity outweighs raw ANN throughput. Dedicated vector databases still win at billion-scale, multimodal indexing, or high concurrent query loads.
Key Takeaways
- Dual-write complexity has a real price tag: Keeping a separate vector store in sync creates consistency bugs, failed syncs, and on-call burden.
- Sparse retrieval deserves a seat at the table: BM25 and hybrid sparse-dense indexes are competitive enough that dense embeddings should no longer be the automatic first choice for domain-vocabulary queries.
- Consolidation is right for most, not all: Corpora well above 100 million embeddings with heavy concurrent loads may still warrant a dedicated system.
- Migration does not require downtime: A dual-read pattern lets you validate recall before decommissioning the legacy store.
What operational costs actually accumulate when you run a dedicated vector store?
Three compounding failure modes only become visible under production load.
Stale vectors: When a document updates in PostgreSQL, the vector in Pinecone does not update automatically. Semantic search returns results tied to stale records.
Dual-write failures: A write succeeds in the primary database but fails silently in the vector store. Indexes drift invisibly, and reconciliation jobs consume engineering time every sprint, indefinitely. One practitioner who stopped using vector databases for RAG entirely documented this in detail.
Authorization mismatches: Semantic results joined to relational data for row-level access control require a cross-system join at query time. No ANN tuning resolves this, the bug is architectural.
"The dominant hidden cost of a dedicated vector database is not infrastructure spend, it is the compounding operational debt of keeping embeddings synchronized with source records that change in your primary database."
When does native vector search in PostgreSQL, Redis, or TiDB match dedicated recall well enough to consolidate?
For corpora under ~100 million embeddings at moderate query concurrency, native vector search is production-acceptable without synchronization overhead. That threshold is a practical rule of thumb, actual limits depend on hardware, index configuration, and query patterns.
pgvector's HNSW index is a serious option for teams already running PostgreSQL. Redis positions itself explicitly as a RAG alternative: if you are already running Redis for caching, adding vector search costs zero additional infrastructure. For distributed SQL workloads, TiDB offers native vector support in the same stack.
All vector-count ranges are author estimates based on published documentation, directional starting points, not independently verified benchmarks. Validate against your specific workload.
| System | Approximate vector range (author estimate) | Index type | Joins to relational data | Operational overhead |
|---|---|---|---|---|
| PostgreSQL + pgvector | Up to ~10M (tuned configs reported to ~50M) | HNSW, IVFFlat | Native (same DB) | Low |
| Redis Vector Search | Up to ~10M | HNSW, Flat | Application-layer | Low-Medium |
| TiDB Vector | ~10M to ~500M | HNSW | Native (distributed SQL) | Medium |
| Pinecone / Qdrant | 500M+ | HNSW, custom ANN | Cross-system join required | High |
| Milvus / Weaviate | 500M+ | Multiple ANN types | Cross-system join required | High |
Is embedding-free RAG with BM25 or sparse-dense hybrid retrieval viable?
For keyword-specific queries and domain-vocabulary documents, BM25 and hybrid sparse-dense retrieval are production-viable and can match or exceed dense retrieval relevance at lower infrastructure cost. This is a practical rule of thumb observed across enterprise RAG deployments, not a claim from a single controlled benchmark.
Hybrid indexes offer a middle path: sparse retrieval for candidate recall, dense embeddings only for reranking the top results. If your queries look like "SOX compliance report Q3 2025," lexical retrieval will often be more precise than nearest-neighbor search over high-dimensional embeddings. Test this against your actual query distribution before assuming the problem is semantic.
The three-signal consolidation test
Consolidate your vector store into your primary database when all three signals are present. This framework is the author's synthesis based on the operational failure modes above, not a published external standard.
- Scale signal: Corpus under ~100 million embeddings, pgvector or Redis may handle it without a dedicated system.
- Join signal: Results filtered against relational data (ACLs, tenant IDs, metadata), co-location eliminates the cross-system join.
- Sync signal: Source records update frequently, the stale vector problem is active and compounding.
When all three fire, you are paying an operational tax for infrastructure that works against your stack's correctness.
Migration requires no downtime. Write embeddings to both the legacy store and the new pgvector column simultaneously. Route shadow traffic through pgvector and compare retrieval quality against actual queries. When recall parity holds consistently, drain traffic to the legacy system and decommission.
Stay with a dedicated system when your corpus exceeds the thresholds above, when query concurrency is high, or when multi-modal embeddings require specialized index types. The 100+ enterprise deployment guide covers vendor selection at that scale.
Frequently Asked Questions
When does native vector search in PostgreSQL match dedicated vector database recall well enough for production RAG?
pgvector with HNSW indexing is production-acceptable for corpora under ~100 million embeddings at moderate query concurrency, as a practical rule of thumb based on publicly documented capabilities. Test against your actual data and hardware, vendor-published numbers matter less than your specific workload.
What are the hidden operational costs of running a separate vector database alongside a primary database?
The three dominant costs are stale embeddings after source record updates, dual-write failures that silently desync indexes, and cross-system round-trips for access control joins. None surface in vendor benchmarks; all compound under production load.
Is BM25 retrieval a viable replacement for dense vector search in enterprise RAG?
For keyword-specific queries and domain-vocabulary documents, yes, hybrid sparse retrieval for candidate recall plus dense embeddings for reranking often delivers strong relevance at lower operational cost. Whether it applies to your workload depends on query structure and document vocabulary; test BM25 against your actual queries before building embedding infrastructure.
At what scale does a dedicated vector database become necessary again?
A dedicated system is warranted when your corpus exceeds ~500 million embeddings, when concurrent query volume would saturate a general-purpose database's connection pool and CPU, or when your embedding modality requires specialized index types general-purpose systems do not support.
Conclusion
Dedicated vector databases are being decommissioned not because benchmarks shifted, but because teams discovered the benchmark never measured what was hurting them: keeping two stores in sync across a live system with access control, frequent updates, and real SLAs. Run the three-signal test. If all three fire, you are paying an operational tax for infrastructure that works against your stack's correctness. Before rebuilding anything, check whether the retrieval problem is actually semantic, a BM25 index already in your stack may solve it without any embedding infrastructure.
Learn from me
Forward Deployed Engineering Bootcamp for Full-Stack Developers, my Maven cohort. Build and ship complete AI products end to end, from React and Node.js frontends to deployed models with caching and observability. Join the next cohort →
Hire us
Traversaal.ai. We're a team of forward deployed engineers solving the toughest AI problems for Fortune 100 companies: document intelligence, agentic data platforms, and real-time web intelligence, deployed in production. Work with our team to deploy your next agentic ecosystem. Talk to Traversaal.ai →
Join us
Want to solve these problems with us? We're always looking for forward deployed engineers who want to ship production AI. jobs@traversaal.ai
