Vector Databases Shouldn't Become New Isolated Islands: How KingbaseES's Multi-Model Fusion Architecture Reduces Data Shuffling

Vector database projects are easiest to make look simple in a demo environment: slice a batch of documents into chunks, call a model to generate vectors, write them into a vector store, then use similarity search to return a few results. Once connected to real business operations, the problems quickly take on a different shape. User permissions sit in the business database, document bodies sit in a file system or document store, vector search runs in a third service, and order, organization, region, and time conditions are scattered elsewhere. Answering a single question requires checking permissions first, then documents, then vector results, and finally stitching several result sets together.

If any one of those updates fails to synchronize in time, the search results can lag behind the business state. A document has been retracted, but its vector index remains; a client has changed their affiliated organization, but the old permission tags still appear in recall results; a piece of knowledge has been re-segmented, and old and new vectors exist simultaneously, making it hard to determine during troubleshooting whether the problem lies in the model, the sync task, or the database query.

This is also why a "vector database" should not be simplistically understood as yet another independent storage system. For systems that require transactional data, document attributes, spatial locations, temporal states, and semantic vectors to all participate in retrieval together, a more sensible direction is to let different data models collaborate within a single database architecture. KingbaseES's converged database positioning is precisely about placing relational, document, vector, spatial, and time-series data capabilities into a unified data foundation, allowing the business to choose models by scenario, rather than setting up a separate database for every type of field.

From Stitching Results Across Three Systems to a Single Explainable Query

Take enterprise policy Q&A as an example. A document administrator uploads policy files to the knowledge base, and the application needs to accomplish four things: confirm which policies the questioner is authorized to see; perform semantic recall from authorized text segments; exclude expired materials based on policy effective dates; and finally return file version, department, and classification level information to the upper-layer application.

In a decentralized architecture, the flow is roughly "check permissions in business DB -> check body text in document DB -> check similarity in vector DB -> filter and stitch at the application layer." Every additional filter condition on this chain adds one more interface interaction and one more field mapping. Permission tags, file versions, and vector records each have their own update transactions, and failure at any step can produce a partially successful state.

A converged architecture does not require stuffing body text, attributes, and vectors into a single column; instead, it allows them to maintain clear table structures within the same database management scope. Body text can reside in document fields or object storage references, metadata in relational tables, vectors in vector columns, and permissions controlled through relational tables and roles; during queries, these conditions are combined through a single SQL statement.

The change depicted in the diagram is not about "kneading all data into one format," but about placing data ownership, permissions, and transaction boundaries into the same manageable system. Relational tables still handle explicit business constraints, document data retains its original hierarchy, vector fields serve similarity search, and time and spatial fields continue to be used according to their own query patterns. The application faces a unified connection and permission system, while the database internally still chooses appropriate storage and indexing methods based on the data model.

Relational Data and Vector Data Must Be Updated Together

The most easily overlooked field in vector retrieval is not the vector itself, but its corresponding business state. A policy segment needs to record at minimum its source file, version number, department, classification level, effective date, and whether it is active. When the vector generation model changes, the model version must also be written into the record; otherwise, vectors from different models are mixed in the same table, and there is no way to replay when recall performance fluctuates.

CREATE TABLE knowledge_chunk (
    chunk_id        bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    document_id     bigint NOT NULL,
    version_no      integer NOT NULL,
    chunk_no        integer NOT NULL,
    title           varchar(300) NOT NULL,
    content         text NOT NULL,
    department_code varchar(32) NOT NULL,
    security_level  varchar(16) NOT NULL,
    effective_from  timestamp NOT NULL,
    effective_to    timestamp,
    is_enabled      boolean NOT NULL DEFAULT true,
    model_name      varchar(80) NOT NULL,
    embedding       vector(768),
    updated_at      timestamp NOT NULL DEFAULT current_timestamp,
    UNIQUE (document_id, version_no, chunk_no)
);

vector(768) represents a fixed-dimension vector column; the dimension must match the model actually used. When changing models, you should not directly overwrite old values; first add a model version or new batch, complete recall regression, then switch is_enabled. This means keeping data around a bit longer, but it separates "model changes" from "business material changes."

Document publishing and vector writing should occur within the same business transaction, at minimum ensuring that publish status, version number, and vector records do not succeed only partially. A simplified transaction snippet follows:

BEGIN;

UPDATE knowledge_document
   SET current_version = 8,
       status = 'PUBLISHED',
       updated_at = current_timestamp
 WHERE document_id = 10086
   AND status = 'READY';

UPDATE knowledge_chunk
   SET is_enabled = false
 WHERE document_id = 10086
   AND version_no = 7;

UPDATE knowledge_chunk
   SET is_enabled = true
 WHERE document_id = 10086
   AND version_no = 8
   AND model_name = 'embedding-v3';

COMMIT;

Whether vector generation has completed must be confirmed by the application's status field or a task table. You cannot treat "file published successfully" as "semantic search is now available," nor can you mark records where vector generation failed as valid. A unified database provides transaction boundaries, but it will not decide for the business whether model generation succeeded.

Semantic Similarity and Business Conditions Must Be Completed in a Single SQL Statement

Taking only the top few results by vector distance easily recalls content that does not belong to the current department, has expired, or has a mismatched classification level. Truly usable retrieval requires writing the business scope into filter conditions first, then sorting by vector distance. The vector fields, similarity operators, and index syntax provided in Kingbase's public documentation can serve as SQL references for similar scenarios; specific dimensions, index types, and parameters still need to be confirmed against the target version's vector component.

CREATE INDEX idx_knowledge_chunk_embedding
ON knowledge_chunk
USING hnsw (embedding vector_cosine_ops);

After the user's question is converted by the model into :query_embedding, the hybrid query can be written as:

SELECT chunk_id,
       document_id,
       version_no,
       title,
       content,
       department_code,
       security_level,
       effective_from,
       embedding <-> CAST(:query_embedding AS vector(768)) AS distance
FROM knowledge_chunk
WHERE is_enabled = true
  AND department_code IN ('FINANCE', 'RISK')
  AND security_level <= :user_security_level
  AND effective_from <= current_timestamp
  AND (effective_to IS NULL OR effective_to > current_timestamp)
ORDER BY embedding <-> CAST(:query_embedding AS vector(768))
LIMIT 8;

The results of this SQL can be directly handed to an upper-layer re-ranking or generation service. Permissions, version, and validity period have already been handled in the database conditions; the application does not need to retrieve dozens of candidate records and then filter them one by one. Similarity ranking is still only a recall mechanism; the final answer should still retain the file number, version, and cited snippet to make it easy for business personnel to trace back to the original material.

Vector retrieval can also be combined with ordinary keywords. Titles, policy numbers, and department codes are explicit fields suitable for equality or fuzzy conditions; semantic vectors are suitable for handling synonymous expressions. Writing the two types of conditions separately in SQL makes the source of results and the reason for filtering clearer:

SELECT chunk_id, title, content
FROM knowledge_chunk
WHERE is_enabled = true
  AND department_code = 'RISK'
  AND (title LIKE '%' || :keyword || '%'
       OR content LIKE '%' || :keyword || '%')
ORDER BY updated_at DESC
LIMIT 20;

Keyword queries and vector queries do not necessarily have to replace each other. Precise fields like policy numbers, device models, and contract numbers should still be filtered first; when the user's phrasing differs from the original text's wording, let vector similarity handle supplementary recall. Placing both types of retrieval into a unified data model allows the application to combine them by scenario, rather than establishing a completely different data synchronization chain for each retrieval method.

From user permissions to file versions to vector distance, all conditions can leave auditable query records on the database side. When "material that should not have been recalled appears," you can sequentially check the permission table, validity period conditions, vector batch, and query parameters, rather than first exporting results from three systems and then manually comparing them.

Retrieval Results Must Also Be Replayable

Enterprise knowledge retrieval cannot just record the final generated answer. A single recall should at minimum save the query time, calling account, model version used, vector batch, business filter conditions, and returned snippet IDs. Only then, when a user reports an incorrect answer, can you re-run with the same set of conditions to confirm whether it was a change in material version, a change in permission rules, or a change in the vector model.

The audit table does not need to save the full question and full document; it can record a de-identified query identifier and result references:

CREATE TABLE retrieval_audit (
    request_id       varchar(64) PRIMARY KEY,
    user_code        varchar(64) NOT NULL,
    model_name       varchar(80) NOT NULL,
    query_hash       varchar(128) NOT NULL,
    filter_snapshot  text NOT NULL,
    result_chunk_ids text NOT NULL,
    created_at       timestamp NOT NULL DEFAULT current_timestamp
);

filter_snapshot saves the department, classification level, and validity period conditions used at the time; result_chunk_ids saves the recalled snippet IDs. The business system needs to restrict query permissions on this table and clean it up according to the audit cycle; query hashes also cannot be treated as a permanent anonymization method. For high-risk businesses, the final cited file version and manual feedback conclusion should also be saved, turning retrieval regression from "it feels more accurate" into a comparable set of results.

Recall thresholds must also be determined through business samples. Returning a fixed top 8 does not guarantee all 8 are relevant, and distance values cannot be directly compared horizontally across different models. When upgrading a model, you should use the same set of questions to compare hit snippets, false recalls, permission blocks, and no-answer scenarios before deciding whether to switch vector batches. Unified storage makes this kind of replay easier to execute, but judging retrieval quality still requires business annotation and a stable test set.

Multi-Model Fusion Is Not Unconditional Merging

A unified foundation solves the problem of data management boundaries; it does not mean all workloads should be placed in the same instance, the same table, or the same index. Vector index construction consumes memory and CPU, bulk document import generates write spikes, and spatial data and time-series data have their own access patterns. Resource isolation, tablespace planning, and backup strategies must still be designed separately by workload.

Data security must also keep pace with model changes. Vectors themselves may contain personal information, contract content, or characteristics of medical images; access levels cannot be lowered just because they are not readable text. Application accounts should only read authorized views, the task account generating vectors should only write to specified columns, and the operations account is responsible for index and capacity management; the retention cycles for original documents and vector indexes must also be incorporated into data governance together.

Model updates are another action that requires an audit trail. An Embedding model upgrade can affect recall order, thresholds, and result counts. model_name, dimension, generation time, and batch number should all be recorded in the table, and regression testing should at least cover popular questions, permission boundaries, expired documents, and duplicate snippets. Without this information, when vector results change, you can only guess the reason based on intuition.

The Value of Unified Management Must Translate into Operational Actions

What a multi-model fusion architecture reduces first is redundant data shuffling. When business state updates, permission tags and vector records can be processed within the same transaction boundary; when a document is taken offline, there is no need to wait for another system's sync task to complete; during queries, structured conditions and similarity ranking can be expressed by a single SQL statement. The objects operations personnel focus on converge from multiple sync queues, multiple accounts, and multiple field mappings into four categories of problems: data models, indexes, permissions, and resources.

It also allows migration and expansion to proceed in stages. First bring relational tables and document metadata into unified management, then add vector fields by business priority; first get keyword retrieval running stably, then connect semantic recall. Each step can be proven with result sets, permission verification, and regression question sets, rather than replacing all storage components at once.

After vector databases truly enter enterprise systems, the evaluation criteria should not just be whether a similarity query can return a few results. More critical questions are: whether document versions are consistent with vector batches, whether permissions take effect before recall, whether failed business transactions leave orphaned vectors, and whether historical results can be reproduced after a model upgrade. KingbaseES's multi-model fusion architecture provides a path for placing this data within the same management boundary; the remaining work is still to design the fields, indexes, permissions, and regression rules solidly.