Why Enterprise AI Hits a Wall at the Data Layer Despite Powerful Large Models

In a recent OceanBase AI Database webcast, the author reflects on why the biggest obstacle for enterprise AI is no longer the model but the data foundation that agents need to operate on.

Why Enterprise AI Gets Stuck at Data

Over the past three years, most AI budgets have been spent on models, compute, and knowledge bases. However, once AI is embedded in business workflows, projects often encounter a paradox: even as large models become stronger, business value remains limited because the models solve general intelligence while enterprises need business‑specific intelligence.

Agents must understand business context, handle multimodal inputs (documents, images, audio, video), call real‑time business data, and avoid polluting production environments. If these challenges are not addressed, AI cannot be reliably integrated into core processes.

OceanBase’s Four Pillars for an AI‑Native Database

OceanBase defines its AI database with four keywords: integration, multimodality, agent‑friendliness, and openness. The goal is to provide a production‑grade data base for agents.

OceanBase AI Database = Lake+DB integrated · Multimodal · AI native

Three Core Problems OceanBase Aims to Solve

1. Changing Data Shapes – Traditional databases manage structured tables. Agents now need to consume contracts (PDF), call recordings, meeting minutes, medical reports, images, videos, risk rules, knowledge snippets, conversation memories, vectors, and JSON. Scattering these assets across object storage, file systems, search engines, and vector stores forces agents to stitch context repeatedly, adding latency, redundancy, and consistency risk.

2. Evolving Data Flow – The classic pipeline

Transaction DB → ETL → Data Warehouse / Lake → Search / Vector Store → RAG / Agent

is slow and heavyweight. OceanBase proposes a “data flywheel”: agents generate data, which is fed back to improve models and knowledge, creating a fast‑feedback loop.

3. New Risks from Agents – Humans back up and review before changing production data; agents may act autonomously, risking unintended writes. OceanBase introduces forked databases, copy‑on‑write, diff/merge, and rollback mechanisms to sandbox agent actions and ensure safe trial‑and‑error.

Lakebase: Unifying Lake and DB

Lakebase is the core engine that stores structured, semi‑structured, and unstructured data together while supporting transactional (TP), analytical (AP), and AI workloads. It aims to eliminate the need for separate transaction databases, data warehouses, object stores, search engines, and vector stores.

Multimodal Tables and AI Columns

OceanBase’s multimodal table can hold structured fields, text, images, audio, video, JSON, LOB, and vectors in a single table. For example, a contract table may contain contract ID, PDF, full text, key‑clause JSON, embedding vector, risk tags, approval status, and permission info—all governed by the same transaction, permission, metadata, and lifecycle management.

AI columns act as an internal semantic processing pipeline: raw data is ingested, then the database can generate summaries, tags, features, or vectors in‑place, guaranteeing atomic success or failure across all rows.

Hybrid Search: Combining Traditional and Vector Retrieval

Pure vector search often returns semantically similar but business‑irrelevant results. OceanBase’s hybrid search first applies relational filters, full‑text, vector, and graph search to prune candidates, then lets the model re‑rank the high‑value subset.

SQL execution → multi‑path recall & coarse ranking → model processes top candidates

Benchmarks show OceanBase’s vector performance surpasses Milvus, PGVector, and Elasticsearch at equal recall, and its hybrid search outperforms Elasticsearch by over 30% on the MSMARCO dataset.

Agent‑Friendly Features: Safe Trial‑and‑Error

Agents need sandboxed environments. OceanBase’s forked database creates an isolated sandbox for each agent, records diffs, merges only after verification, and can roll back instantly. This mirrors code‑branch workflows within the database.

Fork: create independent sandbox
Diff: inspect changes
Merge: apply after approval
Rollback: revert on failure

A real‑world case is Ant Financial’s “AfU” health assistant, which runs billions of queries. It uses forked databases to evaluate and iterate on policies without contaminating production data.

Massive Logical Tables for the Agent Era

Instead of provisioning a physical table per lightweight agent or app (which would explode schema count), OceanBase provides logical tables that map many logical tables onto shared physical resources, supporting millions of small tables that are mostly idle but can be awakened instantly.

JSON Table for Dynamic Schemas

The “Lingguang” low‑code AI app platform creates ad‑hoc schemas that are serialized as JSON in a wide‑column KV table. Traditional SQL operators (SUM, SORT) cannot run efficiently on raw JSON, and creating a physical table per app would overwhelm the system. OceanBase’s JSON Table lets developers write standard SQL, which the SDK translates to JSON writes while preserving indexing, aggregation, and sorting capabilities. Hot tables can later be migrated to physical tables for higher performance.

Product Family: Lakebase, DataStudio, DataPilot, PowerMem, PowerRAG, OSI Semantic Layer

The release bundles a full stack: Lakebase (core engine), DataStudio (data development and governance), DataPilot (business‑level AI agent), PowerMem (agent memory), PowerRAG (enterprise knowledge base), and OSI (semantic layer for business concepts). This stack moves from raw data storage to semantic understanding, governance, and finally to business‑level query and reporting.

Conclusion

Enterprise AI competition is shifting from model selection to data infrastructure. Companies that build a complete, multimodal, agent‑friendly data foundation will achieve more accurate context, stronger security, and faster iteration, ultimately delivering AI applications that truly impact business.