OceanBase Lakebase: A Unified Data Foundation for AI-Native Applications

Enterprises Have Data. AI Needs Context.

Enterprise data systems were built around clear boundaries. Databases handled transactions. Data warehouses handled analytics. Data lakes stored large-scale raw data. Search engines indexed documents. Vector databases powered semantic retrieval.

That separation worked when applications were mostly deterministic and data was mostly structured. AI-native applications behave differently.

An AI application does not only read rows from a database. It may need a customer profile alongside images, audio and video recordings, PDFs, web snapshots, vector embeddings, and JSON documents — often for the same business entity. An agent may also need persistent memory, session context, business state, execution history, and a safe place to test changes before acting.

In many enterprises, these data assets already exist. The problem is that they live across different systems, with different metadata, access controls, freshness guarantees, and processing pipelines. The result is a fragmented data stack that makes AI applications harder to build, harder to govern, and harder to run in production.

This is the problem OceanBase Lakebase is designed to address.

What Lakebase Is

Lakebase is the core data engine of OceanBase AI Database. It is designed to bring multimodal data management, online serving, real-time analytics, hybrid search, and open compute into one architecture.

It is not a separate data lake. It is not a traditional database with a few AI features added on top. It is an attempt to rethink how enterprise data should be stored, managed, searched, processed, and served when AI-native applications become part of production systems.

The core idea is simple: structured business data and multimodal data should be managed under one data foundation, with consistent metadata, permissions, lifecycle management, and query access.

For AI applications, this matters because context is not stored in one format. A complete business fact may include a relational record, a document, an image, a transcript, a JSON object, a vector embedding, and model-generated labels. Lakebase allows these different forms of data to be managed and used together, instead of forcing teams to stitch together multiple systems for every AI workflow.

Multimodal Data in One Table Semantics

A key design in Lakebase is the multimodal table.

In a traditional database, a table usually represents structured fields: IDs, timestamps, amounts, statuses, and other typed columns. In Lakebase, a table can also describe richer business entities that include documents, images, audio, video, JSON, large objects, vectors, and model-generated results.

This does not mean every object must be physically stored in the same way. Different data types may use different storage layouts depending on size, access pattern, and cost. But from the user’s perspective, they can be managed under one table model, one metadata system, and one governance framework.

This gives AI-native applications a more natural data model. A customer service case, for example, can include structured ticket fields, chat history, call recordings, uploaded images, diagnostic logs, and embeddings. A logistics record can include order metadata, route events, driver notes, proof-of-delivery images, and semantic features. These are not separate pieces of data from the business perspective. They are different representations of the same entity.

Lakebase makes that entity easier to store, search, govern, and process as a whole.

AI Columns: Bringing Model Results into the Data Pipeline

Lakebase also introduces the idea of AI columns.

AI columns allow model-generated outputs such as embeddings, summaries, labels, categories, or extracted features to be materialized as columns in the data system. Instead of moving data out to an external pipeline, generating semantic results, and writing them back manually, teams can bring model processing closer to the data.

This is useful for several reasons.

First, it shortens the data processing chain. The fewer systems involved, the fewer places where data freshness, schema mapping, and error handling can break.

Second, it makes AI-generated results easier to govern. Embeddings and labels are no longer hidden artifacts in a separate pipeline. They become part of the managed data asset.

Third, it supports more reliable retry and consistency mechanisms. In production AI workflows, embedding generation, summarization, and feature extraction may fail, need retries, or need to be regenerated when source data changes. Treating these outputs as managed columns gives teams a clearer operational model.

Hybrid Search Built into the Data Foundation

AI applications need search, but not just one kind of search.

Keyword search is still important when users know the terms they are looking for. Vector search is useful when semantic similarity matters. Structured filtering is necessary when business rules, permissions, time ranges, product categories, or customer segments must be respected.

In many AI stacks, these capabilities are split across different systems: a transactional database, a search engine, a vector database, and a data pipeline to keep them in sync. That architecture works for prototypes, but it becomes difficult to operate when the application needs fresh data, consistent permissions, and production reliability.

Lakebase brings structured filtering, full-text search, and vector search into one query path. This allows AI applications to retrieve AI-ready context from fresh operational and multimodal data without relying on multiple external indexes that may drift from the source data.

For agents, this is especially important. A stale search result is not just a bad answer. If an agent uses stale context to make a decision or trigger an action, it can become a production risk.

Built for Agent Workloads

Agents change the way databases are used.

A traditional application usually follows predefined workflows. An agent may read, write, search, plan, test, modify state, generate intermediate results, and call tools repeatedly. It may also run concurrently with many other agents, each with its own memory, context, permissions, and execution history.

Lakebase is designed to support this kind of workload.

It provides a foundation for storing and searching agent memory, session context, business state, and execution records. It also supports isolated data environments through database branching and sandboxing, so agents can test changes without directly impacting production data.

For large numbers of AI-generated applications or lightweight agents, Lakebase also supports finer-grained data isolation patterns. This is useful when each application needs its own schema and SQL capabilities, but the data volume per application is small. Instead of creating a large number of physical databases or tables with high metadata overhead, the system can provide logical isolation on shared infrastructure.

The goal is not only to help agents retrieve data. It is to help agents operate safely, repeatably, and at scale.

Open Storage and Open Compute

AI-native workloads will not run inside one engine only.

SQL remains essential for transactional and analytical workloads. Spark is widely used for large-scale data processing. Ray and related frameworks are increasingly used for AI data processing and distributed model workloads. Enterprises also need to preserve existing investments in object storage, open table formats, and data lake infrastructure.

Lakebase is built with this reality in mind.

It supports S3-compatible object storage and open table formats such as Iceberg, while allowing compute engines such as SQL, Spark, and Ray to work on shared data and metadata. This reduces the need to copy data between systems or rebuild a separate data foundation for every new engine.

Open formats are valuable because they reduce lock-in and improve interoperability. But open formats alone do not provide the full serving, consistency, search, governance, and agent-oriented capabilities required by production AI applications. Lakebase is designed to combine openness with database-grade management and real-time access.

How Lakebase Fits into OceanBase AI Database

OceanBase AI Database includes three major product layers.

Lakebase is the core engine. It manages multimodal data, hybrid search, open storage, open compute, real-time serving, and agent-ready data environments.

DataStudio is the data production, governance, and service workbench built on top of Lakebase. It helps teams ingest, process, govern, model, and serve data so that enterprise data assets become usable by applications, agents, and business users.

DataPilot is the business-facing data intelligence agent. It allows business users to interact with trusted enterprise data through natural language, generate analysis, ask follow-up questions, and turn data into reusable business insight.

Together, these products form the OceanBase AI Database system: Lakebase provides the data foundation, DataStudio makes data manageable and serviceable, and DataPilot helps users consume data intelligence directly.

Two Deployment Paths

Enterprise customers rarely start from a blank slate. Many already operate databases, data warehouses, data lakes, object storage, and analytics platforms. Lakebase is designed to support both new AI-native workloads and existing data environments.

For new AI applications, Lakebase can be deployed as a standalone data foundation. This is suitable when a team wants to build a new multimodal data platform from the ground up, with storage, search, processing, and serving capabilities in one architecture.

For existing environments, Lakebase can also connect with current data lakes, object storage, and databases. In this path, customers can add multimodal processing, hybrid search, AI columns, and agent-ready data services without moving all data into a new system first.

This matters because AI adoption should not require enterprises to discard years of data infrastructure investment. The better path is to make existing data more usable for AI while providing a cleaner foundation for new workloads.

Where Lakebase Helps

Lakebase is useful in scenarios where structured data and multimodal data need to be processed together.

In intelligent customer service, an agent may need to combine account data, order history, policy documents, chat logs, call transcripts, and uploaded images to answer accurately and take the right action.

In financial services, analysts and AI applications may need to connect market data, transaction data, research reports, announcements, compliance documents, and semantic search results under one governed system.

In autonomous driving and robotics, teams may need to manage large volumes of video, image, sensor, and metadata records, then search for specific events, generate training samples, and feed downstream model pipelines.

In enterprise knowledge applications, teams may need to combine documents, tables, business records, embeddings, and permissions so that AI-generated answers are accurate, traceable, and safe to use.

Across these scenarios, the common need is not just storage. It is a governed, searchable, real-time, and open data foundation for AI.

Closing

AI-native applications are pushing enterprise data systems beyond the boundaries they were originally designed for. The challenge is no longer only how to store more data, or how to run faster queries. The challenge is how to make enterprise data usable by models and agents in a way that is real-time, consistent, governed, and scalable.

Lakebase is OceanBase’s answer at the data engine layer.

It brings multimodal data, hybrid search, open compute, and database-grade management into one architecture, so enterprises can reduce fragmented pipelines and build AI applications on a more reliable data foundation.

For us, the purpose of Lakebase is straightforward: help enterprises turn their existing and future data into AI-ready context, without giving up the reliability, consistency, and operational discipline required in production systems.