Designing a Lakehouse AI Database for Production Agents

On June 29, OceanBase launched its lakehouse AI database during an OceanBase Hours webcast. The question is not how to add a few AI functions to a traditional engine, but how to rebuild the data foundation now that agents read, write, search, and modify state in production.

That is the design problem OceanBase CTO Rizhao (Yang Chuanhui) addresses: unify multimodal data, open compute, and database-grade consistency in one Lakebase stack.

Editor’s note

On June 29, OceanBase Hours went live, and OceanBase formally released its lakehouse AI database. The launch also posed three questions to the industry: what is a lakehouse AI database, why does the AI era need lakehouse integration, and how does OceanBase implement that idea from the ground up?

Author | OceanBase CTO Rizhao (Yang Chuanhui)

OceanBase CTO Yang Chuanhui

Mainstream databases have gone through several major shifts: from the earliest OLTP systems, to OLAP splitting off as the data warehouse, and then to big-data platforms. For a long time, database architecture was designed around human applications, deterministic transactions, and structured analytics.

A new shift is underway. An AI agent no longer merely reads data and answers questions. It calls tools, generates code, executes tasks, modifies state, and even participates in business processes. Database users are expanding from human-facing applications to large numbers of autonomous agents. That raises a fundamental question: when thousands of agents concurrently read, write, search, experiment, roll back changes, and generate context, should the database still look like the one we built for yesterday?

I believe the answer is no. AI is changing three things at once:

• Database users are expanding from applications to agents.
• The data managed by a database is expanding from structured data to multimodal data that includes structured, semi-structured, and unstructured content.
• Database workloads are expanding from transactions and analytics to search, context engineering, and AI applications.

An AI database is therefore not a traditional database with a few AI functions bolted on, and it is not a vector database that later adds SQL. It has to solve the data-infrastructure problem that appears when AI enters production systems. Multimodal data needs to be managed on a unified foundation. Online services and offline compute need to converge. Agents need real-time, trustworthy, continuous context. Reads, writes, experiments, rollbacks, and governance still need database-grade consistency and reliability.

This is not an incremental feature update. It is a redesign of database architecture for the AI era.

Start with what the industry is doing.

Databricks and Snowflake started with the lakehouse and the data warehouse, respectively, and continue to add OLTP capabilities.

OceanBase and Oracle started with transactional databases and continue to add OLAP and big-data capabilities.

MongoDB, Milvus, and Elasticsearch started as specialized data stores and continue to add general-purpose database capabilities. Regardless of the starting point, these paths are converging on a unified data foundation that can handle transactions, analytics, search, vectors, and AI compute at the same time.

OceanBase has always insisted on an integrated design.

We first built distributed OLTP to solve scalability and reliability for online transactions. We then added real-time OLAP on top of OLTP, removing the data movement from TP to AP. Last year we released multimodal integration, bringing vector, full-text, JSON, GIS, and related capabilities into the same database engine.

Today, we are taking another step forward with lakehouse integration: combining the database’s real-time transactional capabilities with the lake’s open storage and compute on the same data foundation.

The lakehouse integration I have in mind cannot stop at attaching a data lake to the database, nor can it consist of merely adding a few online query APIs to a lakehouse. To be production-ready, it must bridge at least three boundaries.

First, data forms must be unified. Structured data, semi-structured data, unstructured data, vectors, graphs, and full-text indexes cannot live as separate copies in separate systems. They should be managed under a unified table abstraction.

Second, compute paths must be unified. SQL queries, real-time analytics, hybrid search, Spark ETL, and AI compute on Ray should operate on the same data instead of relying on repeated exports, transformations, and intermediate materialization.

Third, governance boundaries must be unified. Metadata, permissions, row-level control, audit, versioning, and lifecycle must apply consistently to every data type. Otherwise structured fields have access control while vector retrieval bypasses it, and that kind of system cannot enter enterprise production.

That is also the starting point for OceanBase Lakebase:

The bottom layer separates storage from compute. Data resides in object storage, while the compute layer runs independently. AI agent workloads are inherently bursty—any agent may experience a surge on any given day, making every day resemble a small Singles’ Day (November 11) peak. Separating storage and compute allows compute capacity to scale independently: expanding instantly when load arrives and scaling to zero when idle.

In the middle, multimodal tables unify structured, semi-structured, and unstructured data, as well as other multimodal types.

The upper layer supports open compute. In addition to existing SQL compute (OLTP, OLAP, and AI search), it supports Spark for ETL and Daft on Ray for AI processing. Unifying these engines on the same data is the core design goal that distinguishes lakehouse integration from a traditional database.

The lake’s value is openness, elasticity, and cost. The database’s value is transactions, consistency, low latency, and governance. The AI era needs both sets of capabilities together.

One more critical value is easy to miss: real-time behavior.

In the traditional approach, data processing is offline. After processing finishes, results still have to be moved back to the online system before applications can use them, with T+1 or even longer delay.

Lakehouse integration unifies offline processing and online serving on the same data: Spark ETL output is immediately queryable by the SQL engine, and vectors produced by model inference are immediately available to hybrid search. There is no longer a window in which processing is complete but applications still have to wait for synchronization.

Real-time is not achieved by making data movement faster. It is achieved by eliminating data movement.

Traditional relational databases were built around relational tables: INT, FLOAT, VARCHAR, and other columns containing structured data.

Today’s AI databases should be built around multimodal tables.

A multimodal table includes the original relational columns for structured data, plus multimodal columns and AI columns for unstructured data.

Unstructured data can be written into the multimodal table as vectors or text after external embedding or labeling, or written directly as LOB.

OceanBase supports flexible LOB storage.

• If the LOB object is relatively small, store it in-row to save I/O.
• If the LOB object is larger, divide it into chunks, store them in object storage, and keep only their locations in the row.
• If the LOB object is especially large, reference an existing file already in external object storage; the database stores only metadata. Upper-layer applications still see a single table.

On top of the multimodal table, we also designed AI columns. Think of them as real-time computed columns: after data is written, embedding, labeling, and other model computations are triggered automatically, and the results are written back. The most important property is transactional consistency. For example, after a batch of audio is written, embedding and labeling operations must all succeed or all fail. Partial success is not acceptable.

Once the multimodal table exists, the next step is to run AI workloads on it.

Inside an AI database, the basic query pattern evolves from relational lookup to hybrid search—completing relational filters, full-text search, vector search, graph search, and AI compute in the same table.

Why is vector search alone not enough?

Vector search will certainly be one of the most common compute patterns in an AI database. In real scenarios, though, we usually first use relational filters to shrink the global dataset into a smaller candidate set (for example, “only orders from the last 30 days”), then run vector, full-text, and graph hybrid search on that candidate set. The database narrows the range first; the model only processes high-value candidates. Inference costs less, results are more accurate, and the pipeline is easier to control.

In the AI era, search will return to the database itself, just as OLTP and OLAP did, and become a first-class database workload.

On performance, we ran systematic evaluations.

Using the HNSW algorithm, OceanBase delivered substantially better vector-search performance than Milvus, Elasticsearch, and pgvector in 768- and 1,536-dimensional test scenarios at the same recall level.

On hybrid search, evaluated with the MS MARCO dataset, OceanBase hybrid-search performance improved by more than 30% versus Elasticsearch. That is not a theoretical number—it is a reproducible result on a standard dataset.

An agent’s data path is more than SQL queries. It also includes ETL processing, AI inference, and multimodal understanding.

The previous approach usually stitched many different systems together: Kafka for ingest, Flink for stream processing, Spark for batch, HDFS for persistence, ClickHouse for analytics, HBase for wide tables, Elasticsearch for search, and Presto for federated queries.

OceanBase’s lakehouse design is intended to solve that problem.

At the bottom, object-storage-based multimodal tables let multiple compute engines share one copy of the data. OceanBase’s SQL engine handles online queries and transactions; Spark handles petabyte-scale batch ETL; and Daft on Ray handles AI inference. This design addresses data consistency and compute latency across what would otherwise be a multi-system stack.

Because so many open compute engines must be supported, we need a unified open catalog to manage the data. Tables, views, schemas, lineage, row-level permissions, and column-level grants should all be managed here.

Every operation in the OceanBase AI database passes through a unified metadata and access-control plane to prevent unauthorized data access. We already support fine-grained row-level security (RLS).

For agents to enter production, the database must give them an isolated, rollback-friendly operating environment whose cost is low enough.

With Fork Database, you can create a complete database copy in seconds—much like creating a branch in Git. Even a petabyte-scale database can be forked in seconds while consuming space only for incremental changes (with copy-on-write, unmodified blocks continue to reference the same lake storage and are not physically copied).

After creating the branch, you can use it for AI development, testing, and experiments. If an experiment succeeds, commit it; if it fails, roll it back. The incremental storage cost is minimal.

Together with DIFF and MERGE, an agent gets full data version control: Fork creates a branch, DIFF shows differences (down to rows and values), and MERGE writes changes back according to policy. This is not a Git analogy. It is a native SQL-level implementation.

Scale is another dimension. The volume of agent data will be enormous. In the future, there may be hundreds of billions or even trillions of agents running in parallel, each with its own schema and tables—creating a schema-explosion problem.

Traditional databases are optimized for “few databases + massive data”: one cluster hosts dozens of databases, each with billions of rows. The agent scenario is the opposite: tens of millions of agents, each with only a few hundred rows, but an astronomical number of instances.

OceanBase’s logical-table design lets every agent see independent logical tables, while storage underneath is the same physical table. The logical layer absorbs the schema explosion.

Fork Database solves isolated environments; logical tables solve instance scale. Only together can a single agent experiment safely while a massive number of agents run in parallel at low cost.

An AI database is not enough if it is only an engine. Between the engine and the application there is still a missing layer: context.

The context layer has two parts. Data context covers data semantics and governance so AI can understand the enterprise. Application context covers memory and RAG so AI can understand the user.

For memory, an agent cannot simply accumulate context. Its memory must become an evolvable, structured asset. That is why we built OceanBase PowerMem and the PowerMem-based cloud product OceanBase seekdb M0.

OceanBase PowerMem is built on the AI database. Memory retrieval combines structured filters with semantic similarity in a hybrid query. More importantly, PowerMem supports self-evolving memory, including the evolution of both experience and skills.

We validated this with a fair-distillation experiment on AppWorld: the same traces, the same model, and the only variable was the distillation and retrieval scheme. Results: the seekdb M0 scheme reached a 39% pass rate, versus 22% for Hermes; to complete the same tasks, M0 used 6.2 steps versus 10.4 for Hermes; overall token consumption dropped 32%.

On the semantic dimension, high-quality data semantics are what let AI applications truly understand an enterprise. OceanBase OSI is not trying to reinvent a BI semantic layer. It unifies metrics, definitions, raw data, a context graph, and an ontology layer.

• The bottom layer is the semantic layer—metrics, definitions, raw data, and related artifacts—designed on the Ant-OSI semantic-layer standard, compatible with the OSI open standard, and extensively validated inside Ant Group.
• The middle layer is the context graph—large models reason over the graph to improve accuracy.
• The top layer is the ontology layer—unifying business semantics with underlying database semantics, and balancing global and local meaning. The core idea is “semantics as code”: define data semantics once. BI rendering reports, agents generating SQL, and governance tools analyzing lineage all read the same definition.

We also built the DataPilot product on OceanBase OSI. In customer PoC tests across industries, customers reported accuracy far better than other products in the market.

The difference behind that is not the model. It is the quality of semantic context. When AI has accurate business definitions, the accuracy of translating natural language into SQL improves in a fundamental way.

What do all of these capabilities add up to? The most direct answer is a sharp reduction in the number of components.

With a traditional approach, an enterprise needs five to ten systems to fuse multimodal data. Stitching those systems together creates a series of problems: CDC delay, ETL failure and retry, multiple independent operations stacks, multiple permission systems, multiple monitoring and alerting systems, and more.

With the OceanBase lakehouse engine, many systems can be consolidated into one. A single copy of the data ensures consistency, while unified online and offline processing enables real-time access.

Looked at together, the OceanBase AI database architecture can be summarized in three layers.

The bottom layer is the lakehouse engine: multimodal tables running on object storage. On this foundation, it supports open compute through OceanBase SQL processing (OLTP, OLAP, and search), Spark ETL, and large-model AI compute.

The middle layer is the context layer—data context so AI understands the enterprise, and application context so AI understands the user.

The top layer is the application agents we built: a data-development agent for data engineers, and a data-analysis agent for business analysts.

For an enterprise to actually use AI, the most important and most basic step is to manage its own data through an integrated AI database. Only after that data is well managed can the enterprise’s AI become more accurate, more economical, faster, and safer.

A lakehouse AI database is our answer for the AI agent era.

Related reading

Learn more

Finally, you are welcome to follow the WeChat public account “老纪的技术唠嗑局” (Lao Ji’s Tech Talk).

Additional materials are available through the account’s private-message menu.

You are also welcome to join the OceanBase community, or reply in that public account’s private messages with the product you care about (for example OceanBase, seekdb, or PowerMem) to get related materials.