How to eliminate AI data silos — unifying vector, text, and relational queries in one engine
When a database is no longer confined to transactions and reporting, but instead has to power AI inference, knowledge retrieval, and real-time analytics all at once, the data it must understand reaches far beyond the relational table. Vectors, full-text, JSON, arrays, and large objects are becoming the basic vocabulary of the data layer in the AI era. OceanBase takes the approach of natively supporting these multi-model data types inside a single database, so that structured and unstructured data share the same transaction engine and SQL entry point, eliminating the need to shuttle data between systems. This article walks through the technical details of these capabilities, how fused queries work, and how they play out in real AI workloads.
1. Industry Trends and Technical Challenges
The rapid adoption of GenAI is redrawing the boundaries of what a data layer must do. Training and inference on large models consume not only structured transactional data, but also text, images, audio and video, logs, and vectorized representations. A single end-to-end AI request — whether RAG retrieval, intelligent recommendation, or an Agent workflow — often has to fetch a user profile, a behavioral sequence, document fragments, and their corresponding embeddings together, all within milliseconds. This imposes three direct requirements on the data layer: native support for multi-model data types, real-time freshness so data is analyzable the moment it lands, and the ability to combine structured filtering, vector recall, and full-text matching into a single fused query.
Yet the mainstream approach today still stitches together several specialized systems: a relational database for transactional data, a vector database for embeddings, object storage for raw files, and a message queue to tie them together. Each system looks fine on its own metrics, but stacking them creates a fresh round of data fragmentation. The moment the business needs a cross-modal composite query — say, “filter a target segment by user profile, then run a vector nearest-neighbor search over their review text” — data has to be synchronized and joined across multiple systems, and freshness, consistency, and development complexity all blow up at once.
The governance cost is just as significant. With multiple metadata, permission, and lineage systems coexisting, enterprises struggle to build a unified view of their data assets. Different engines expose different query interfaces (Spark SQL, Flink SQL, dedicated vector APIs), so access control and governance standards fragment accordingly. Add the redundant storage, duplicated computation, and operational overhead of running several platforms in parallel, and a unified multi-model architecture shifts from an architectural preference to a hard TCO requirement.
2. A Panorama of OceanBase Multi-Model Data Types
Answering these challenges is not about simply wrapping several engines together; it is about letting multiple data models coexist natively within one storage, transaction, and SQL system. OceanBase is a distributed, multi-model integrated database that, in real-time analytics scenarios, handles structured, semi-structured, and unstructured data on a single SQL engine. Because all multi-model data shares one ACID transaction engine and one unified SQL entry point, cross-system data movement is eliminated at its root, and “one copy of data, many dimensions of analysis” becomes the default. Below we look at the role each of the five core data types plays.
2.1 LOB (Large Object)
LOB is the storage foundation of multi-model capability. The multimodal data in AI scenarios — images, text, audio, video — are all essentially large objects, and how efficiently they can be stored and accessed directly determines the throughput of model training and inference above. Through its SQL interface, OceanBase supports up to 512 MB per column and provides efficient TB-scale large-object access via the DBMS_LOB package, allowing bulky data such as video frame sequences, long documents, and raw logs to sit alongside structured fields. How solid this layer is determines how far the multi-model indexes and operators above it can go.
2.2 JSON
JSON plays a different role across three kinds of scenarios. In transactional workloads it serves as a schemaless, flexible column, well suited to write paths where the business structure evolves frequently. In analytical workloads, JSON multi-value indexes make flexible computation over multi-dimensional tags possible, without rebuilding the table schema for every tag combination. And in AI workloads, JSON acts as the bridge between models and applications — the standard input and output format for Agents and workflow pipelines.
Under the hood, OceanBase offers a rich set of computational expressions and multi-value indexing, so that complex JSON path expressions can execute efficiently with index support. On the storage side, it uses a JSON Binary format to optimize random reads and writes, and builds structured encoding on top of it: by extracting shared Schema information from structurally similar JSON documents, it further improves the compression ratio and markedly speeds up queries based on JSON Path. As a result, JSON retains its flexibility while approaching the execution efficiency of native columns under analytical loads.
2.3 Array / Roaring Bitmap / Map
Collection types address a class of problems that traditional relational models handle poorly: high-cardinality tags combined with large-scale analytics. Roaring Bitmap and Map target high-end data-mining scenarios such as large-scale tag analysis, audience segmentation, and deduplicated aggregation, using bitmap compression and on-demand decoding to dramatically cut memory and compute overhead. Array is a better fit for workloads that must preserve order and duplicate elements — log retrieval, behavioral trails, multi-dimensional tags — letting a variable-length event sequence be expressed within a single field. Pushing these types down into the database kernel means that recommendation, risk control, and similar workloads no longer need extra middleware for every collection operation.
2.4 Vector Type
The vector capability follows a fully in-house path built on vector algorithms plus the database, rather than bolting an external vector engine onto the side of a relational database as a plugin. The direct payoff of this choice is that the vector index can be deeply coupled with the relational query optimizer and transaction system: data is searchable the moment it is written, and index maintenance shares the same consistency semantics as DML. In public benchmarks such as VectorDBBench, OceanBase’s vector retrieval performance surpasses that of typical open-source vector database competitors, which means moving vector workloads into the primary database does not come at the cost of performance.
2.5 Full-Text Search
Full-text indexing is a native component in OceanBase, covering keyword-centric retrieval scenarios such as document search and log analysis. More importantly, full-text indexing can work alongside vector retrieval within a single SQL statement to form Hybrid Search: the keyword side handles exact matching and explainability, while the vector side handles semantic recall and similarity ranking. This combination maps precisely onto the dual demand of knowledge retrieval — to find accurately and to understand the meaning — and forms a key foundation for RAG-style applications.
3. How Multi-Model Capabilities Work Together in a Single SQL
Offering multiple data types within one system is not enough; the real value lies in whether they can work together in a single SQL statement. OceanBase is designed so that a multi-model query is no longer “an assembly of several single-model queries,” but a single plan understood by the optimizer and execution engine as a whole.
3.1 Fused Query Patterns
The most common fusion pattern is joint analysis of structured and semi-structured data. Standard SQL can directly filter, aggregate, and join over JSON fields and Array columns, with multi-value indexes ensuring such queries do not degrade into full table scans. The second pattern combines structured conditions with vector similarity search — for example, using a WHERE clause on a user-profile table to narrow down a segment, then ranking by vector distance in ORDER BY, all without any cross-system join. The third pattern is hybrid retrieval that uses structured filtering, full-text search, and vector retrieval together: keyword recall and semantic recall are merged within one query, and the optimizer decides the execution order. This is the core source of RAG recall quality.
The following is illustrative pseudo-code showing what a fused query looks like at the syntax level:
SELECT d.doc_id, d.title,
MATCH(d.content) AGAINST ('OceanBase multi-model') AS bm25_score,
VECTOR_DISTANCE(d.embedding, :query_vec) AS vec_dist
FROM docs d
WHERE d.tenant_id = 1001
AND JSON_VALUE(d.tags, '$.category') = 'whitepaper'
AND ARRAY_CONTAINS(d.audience, 'architect')
ORDER BY 0.4 * bm25_score - 0.6 * vec_dist DESC
LIMIT 20;
This single query uses structured conditions, a JSON path, an Array containment check, full-text BM25 scoring, and vector distance all at once, and every operator is scheduled within one execution plan by a unified optimizer.
3.2 How the Underlying Engine Accelerates Multi-Model Analytics
Making these query patterns genuinely fast relies on several mutually reinforcing engine features. The first is a unified optimizer and execution engine: multi-model queries share the same cost model, vectorized execution engine, and parallel framework. The optimizer maintains a separate cost metric for columnar scans, automatically chooses a row-store or column-store path based on the shape of the data, and uses AUTO DOP to decide the degree of parallelism — no manual tuning required.
The second is a unified storage engine with hybrid row-column storage: incremental data accepts transactional writes in row-store form, while baseline data lands in column-store to speed up analytical scans, and the user’s DML operations remain completely unaware of the distinction. Multi-model types follow the same architecture; JSON, Array, and vectors all benefit on the column-store side from columnar compression and the scan savings of Skip Index.
The third is the vectorized execution engine: batch processing combined with SIMD instruction acceleration, with the batch size adapting to data characteristics, and TP and AP sharing the same execution framework. This mechanism applies not only to traditional numeric aggregation but also to multi-model operators such as JSON Path evaluation, Array element matching, and vector distance computation, so that “one SQL across multiple models” requires no performance compromise.
The fourth is a decoupled storage-compute architecture: the full dataset resides in object storage to keep costs down, while hot data is served through a local cache to guarantee query performance, and multi-model data needs no special treatment at this layer. Layered on top of the kernel-level integration of Btree indexes, JSON multi-value indexes, full-text indexes, and vector indexes, the entire multi-model query path — from storage through indexing to execution — is closed within a single stack.
4. Application Scenarios
Placing these capabilities into concrete workloads reveals how much a unified multi-model architecture simplifies the end-to-end design.
In intelligent recommendation and personalized marketing, the user profile is typically a set of structured fields, the behavioral sequence is well suited to Array, and product descriptions exist as vectors. With OceanBase’s fused queries, the recall stage can complete profile filtering, behavior-pattern matching, and product vector nearest-neighbor search in a single SQL statement, then hand off to a ranking model for scoring — the whole pipeline with no back-and-forth data movement between an OLTP database and a vector database.
In RAG knowledge-based Q&A, full-text search over enterprise documents, paragraph vector recall, and structured metadata filtering can all converge into one database. The retrieval stage leverages both keyword and semantic signals, permission and tenant boundaries are guaranteed natively by the database, and the context fragments needed to generate an answer can be fetched in a single query — noticeably reducing both the latency and the complexity of the end-to-end pipeline.
In real-time risk control, transaction records accept TP writes in row-store form, user tags carry multi-dimensional attributes as JSON and Bitmap, and anomaly patterns are represented as vectors. When a transaction arrives, the engine can complete rule-based hard-condition filtering, tag-based segmentation, and vector-based matching of similar suspicious patterns in milliseconds, fusing the multimodal signals into a single comprehensive judgment — avoiding the serial calls between a rule engine and a vector service that traditional architectures require.
In multimodal data lake integration, OceanBase connects to external data sources such as CSV, Parquet, ORC, and HDFS through its external table capability, bringing unstructured data that previously sat in the data lake into unified SQL analysis. No separate ETL pipeline is needed between the structured primary database and external lake data; teams can access internal and external tables with the same SQL semantics, turning the data lake from an “analytics island” into just another storage medium under a unified engine.
5. Summary and Outlook
Returning to the original premise, a unified multi-model architecture matters because it directly answers the two questions the AI-era data layer must solve: how to eliminate a new round of data silos, and how to reduce architectural complexity without sacrificing freshness or consistency. OceanBase’s differentiated positioning is not “hanging yet another vector engine next to the database,” but full-stack native integration of multi-model capabilities — from storage format and indexing system to optimizer and execution engine.
From an engineering standpoint, the value of this integration only grows as AI applications deepen: when Agents and workflows become the new data consumers, a unified SQL entry point, a unified permission model, and a unified execution engine will directly determine how fast the applications above can iterate. OceanBase will continue to strengthen full-text search, fused queries, and large-scale unstructured data processing, and round out a more complete set of data service interfaces around AI Agent scenarios — making “one copy of data, serving many forms of intelligence” a capability that engineering teams can rely on by default.
Top comments (0)