Vector Search Breaks When It Lives in a Separate Database
Standalone vector databases create a synchronization tax that grows with every business filter added to a query. When permissions, document versions, and embeddings drift out of alignment, the recall results are silently wrong, and debugging requires manually correlating logs across three systems. A unified transactional boundary turns that class of failure into a straightforward database constraint violation.
Enterprise vector search falls apart when permissions live in one database, documents in another, and vectors in a third. A document retraction that doesn't sync to the vector index, a permission change that misses the recall step, or a model upgrade that leaves old and new vectors mixed together all produce answers that look plausible but are wrong in ways no one can trace. The fix is not to cram everything into one column but to manage relational metadata, document bodies, vector embeddings, and temporal conditions inside the same transactional and query boundary.
KingbaseES's multi-model approach keeps each data type in its own table structure while letting a single SQL statement combine business filters with vector distance ordering. A query can check department membership, security clearance, and effective dates before ranking by cosine similarity, and the whole thing runs in one transaction. When something goes wrong, the audit trail points to a specific condition, not a mystery across three systems.
Model upgrades and document versioning become manageable because the database records which embedding model produced which vector batch. Regression testing can replay the same questions against old and new vectors to measure recall changes, rather than relying on gut feel. The architecture doesn't eliminate the hard work of setting thresholds, annotating test sets, or isolating workloads, but it stops data shuffling from being the thing that breaks first.
The standard vector-database demo, chunk, embed, search, top-K, ignores the reality that most enterprise queries need five or six WHERE clauses before similarity ranking even matters. The industry's fixation on ANN benchmark numbers has obscured the fact that recall quality is dominated by stale metadata, not index recall speed.
Treating a model upgrade as an in-place column overwrite is a data-loss event in disguise. Without a model_name column and a batch-switching pattern, an organization permanently loses the ability to explain why a recall result changed, which makes vector search un-auditable for any regulated use case.
The argument for a separate vector database has always been about specialized indexing, but the operational cost of keeping permissions, versions, and vectors in sync across systems is higher than most teams estimate. A converged database that supports HNSW indexes inside the same transaction scope eliminates an entire class of distributed consistency bugs.
Keyword search and vector search are often pitched as competitors, but the article's SQL examples show they are complementary filters inside the same query. Exact-match fields handle the structured half of a question; vectors handle the fuzzy half. Splitting them into separate services forces the application to merge result sets, which is strictly worse than letting the query planner do it.