From Distributed OLTP to AI Lakebase: Five Architectural Shifts for Production AI

This post is adapted from Charlie Yang’s keynote at OceanBase Hours, It expands on his discussion of OceanBase’s evolution from distributed OLTP to AI Lakebase. Watch the full session on YouTube.

For years, the database industry solved new workload demands by adding new systems: OLTP for transactions, OLAP for analytics, and separate big-data platforms as data volumes grew. That worked when humans were the primary consumers of data and some delay between systems was acceptable.

AI changes these design assumptions. Agents operate continuously, interact with both structured and unstructured data, and often need to reason and act on the latest business state. A pipeline built around repeated data movement makes it difficult to preserve freshness, consistency, and governance across the full workflow.

A unified database gets us part of the way there, but it is not enough. In this post, I want to explain the five architectural shifts that take us from a unified distributed database to an AI Lakebase: from relational tables to multimodal tables, lookup to hybrid search, human-friendly to agent-friendly, SQL compute to open compute, and schema to semantics.

For OceanBase, this builds on fifteen years of work unifying transactions, analytics, and multi-model access in one engine. The next step is extending that foundation for AI.

Where this starts: a distributed OLTP database

OceanBase began as a distributed OLTP database, and for most of its life that was the entire product thesis. A single cluster scales past a thousand servers, with nodes added or removed online. Cross-city deployment survives the loss of a data center with RPO = 0 and RTO under 8 seconds. Online compression cuts storage footprint by 70–90% — and at scale, storage is where most of the money goes.

We took that to the TPC-C benchmark twice — 60.88 million tpmC in 2019, then 707,351,007 tpmC in 2020 across a 1,557-node cluster, holding throughput jitter under 1% where the specification permits 2%. The more durable fact is the second one: that audit was the first to include ACID test cases written specifically for distributed transactions, and OceanBase was the first distributed database to pass them. Throughput is a snapshot of a configuration. Correctness is a property of the system.

Benchmarks establish a ceiling; production sets the floor. In Alipay production, OceanBase handles a peak of 61 million operations per second, with 6 PB in a single instance and 320 billion rows in a single table, in a 200-node cluster. Those are the conditions the architecture was actually shaped by.

Extending the same engine into analytics

From that transactional foundation, we chose to unify workloads rather than build separate systems around them.

One storage engine supports row, column, and mixed layouts, allowing transactional and analytical workloads to operate within the same architecture. On top of that sit one transaction engine, one SQL engine supporting both MySQL and Oracle dialects, and a multi-model layer exposing KV, JSON, wide-column, full-text, and vector access against the same underlying tables.

The important point is not how many capabilities fit into the engine. It is what those capabilities inherit from the foundation beneath them.

Vector search, for example, inherits Paxos replication, high availability, and online scaling because it is part of the same distributed system rather than a separate vector database.

That unification held on the analytical side too. OceanBase set the TPC-H world record at 30 TB in 2021, reaching 15,265,305 QphH. More recently, on ClickBench, OceanBase 4.4.2.2 reported a total response time of 11.76 seconds versus 14.263 seconds for ClickHouse 24.4 on the same m5d.24xlarge instance.

A general-purpose database engine was not expected to compete with a specialist analytical system here at all.

Unification is necessary, but not sufficient

A unified architecture is very good. But a database alone is not enough for AI workloads.

First, multimodal data such as documents, audio, video, and images is often too large and too cold to live entirely in a transactional storage tier. That pushes the architecture toward storage-compute separation on object storage.

Second, many AI workloads are fundamentally batch workloads, such as generating embeddings, transcribing media, or running inference across millions of rows. These jobs are not naturally expressed in SQL, nor should they be. They require an open compute layer.

Third, agents behave very differently from human database users. They can arrive in enormous numbers, each requiring an isolated view of the data, and they cannot wait for someone to provision a database manually.

Those requirements lead to five shifts.

Shift 1: from relational tables to multimodal tables

Unstructured data needs to become a first-class column type, rather than a blob referenced by a path somewhere outside the database.

A single table can hold media_id, region, and created_at alongside a raw file stored as a LOB, metadata stored as JSON, and an embedding stored as a vector. To the application, it is still one table.

Underneath, the system decides where the data belongs based on object size.

Small objects stay in-row, so multiple rows can be returned in a single I/O. Larger objects move out-of-row, while the primary table keeps a locator. Very large or cold files can live on external object storage.

The important part is not only where the bytes are stored. It is how the source data and everything derived from it stay consistent.

Embeddings, extracted labels, classifications, and other derived columns can be written in the same transaction as the source data, with the model and model version recorded alongside them.

This gives the source data and its derived data the same permission model, lifecycle, and transactional guarantees. It also avoids the common failure mode where a vector database contains an embedding generated from content that has since changed, or no longer exists, in the system of record.

Shift 2: from relational lookup to hybrid search

A single query can use four different retrieval paths.

Relational filtering defines the scope. Full-text search finds exact matches. Vector search finds semantically similar items. Graph traversal finds related entities.

Those paths resolve together against the same table, instead of across four systems whose outputs must later be reconciled in application code.

The economics matter just as much as the convenience. If the database narrows the candidate set before anything reaches a model, the model only needs to re-rank the highest-value candidates rather than consume the full corpus. That means fewer tokens, lower cost, and tighter control over what the model is allowed to see. Vector search is the retrieval path most often split into a separate system, so it is worth grounding this point in performance.

Against Milvus 2.5.11, pgvector 0.8.0, and Elasticsearch 9.0.0 on a single m6id.4xlarge, with recall held between 0.98 and 1.0 across no-filter, 1%, and 99% selectivity scenarios, OceanBase 4.3.5 sustained higher vector query throughput in every configuration.

Hybrid search inherits that performance rather than bolting it on afterward, because the vector path lives inside the same engine as the other retrieval paths.

Shift 3: from human-friendly to agent-friendly

As AI becomes a more active user of data infrastructure, the database needs capabilities designed for how agents actually work.

One example is database branching. Agents will make mistakes, and human confirmation will still be important in many workflows. Instead of experimenting directly on production data, an agent can fork a database or table, make changes in isolation, and either commit them if the result is correct or roll them back if it is not.

The second challenge is scale. If billions of agents each create their own tables, the result is schema explosion. A logical table layer can give each agent its own data boundary while sharing the same physical table underneath.

This also makes hot-cold tiering more practical. Data from inactive agents can stay in lower-cost cold storage and move to hot storage on demand when activity increases.

That is what agent-friendly infrastructure requires: safer experimentation, much larger scale, and more efficient resource use.

Shift 4: from SQL compute to open compute

Not every AI workload belongs inside a SQL query. Spark is well suited to ETL and batch processing. Daft on Ray can run AI pipelines such as conversion, cleaning, chunking, embedding, and transcription. SQL continues to serve OLTP, OLAP, and hybrid search.

The key is that all of these compute engines can operate on the same multimodal tables backed by the same object storage. This allows different processing engines to work on one shared copy of the data instead of creating and maintaining separate copies for each system.

In a conventional AI data stack, much of the cost and much of the staleness comes not from any single system, but from repeatedly copying data between them. Removing those copies improves both efficiency and freshness.

Shift 5: from schema to semantics

This is the shift that gets underestimated. You can put every modality in one table, index it four ways, and expose it to open compute engines, and an AI still cannot use it well — because a schema tells you a column is a decimal(18,2) named gmv_amt, and says nothing about what that means, how it is calculated, or which of the three similar columns the finance team actually reports.

So the context layer defines meaning as a queryable asset. In our stack this is OceanBase OSI, and it has three layers. At the bottom, a semantic layer carries metric definitions, computation logic, and business definitions. It is built on Ant-OSI, which follows the open semantic interchange specification now incubating at the Apache Software Foundation as Apache Ossie, and extends it with Ant Group's production practice. Above that, a context graph of entities and relationships is built automatically from the data rather than hand-curated, so models have something to reason over. At the top, an ontology layer maps business semantics onto database semantics and reconciles local definitions with global ones.

Semantics live next to the data, not in a BI tool the agent cannot see. The context layer splits in two:

• Data context — the meaning of the enterprise's own data
• Application context — knowledge of the application and the user asking.

The architecture, bottom to top

At the base of the architecture is object storage, with multimodal tables built on top of it.

Multiple compute engines operate across those tables, covering OLTP, OLAP, hybrid search, batch processing, ETL, and AI operators. Above the compute layer sits the context layer, which contains both data context and application context. Applications then sit on top of that context layer.

Two important aspects follow from this architecture.

• The AI data stack gets substantially smaller. A typical enterprise AI stack today runs eleven or more separately operated systems: Kafka, Flink, Hudi, Spark, HDFS, ClickHouse, Redis, HBase, Elasticsearch, an MPP warehouse, Presto. Each has its own scaling model, failure model, security model, and on-call rotation — and the license cost is the small part of that bill. Consolidating onto one engine removes most of that integration surface. Spark and Ray stay, but as compute attached to the same tables rather than as systems with storage and state of their own to operate.
• The online-offline loop closes. In a conventional stack, offline mining produces insights that reach the serving path hours or days later. An agent never sleeps, and it decides at the moment it sees the data. When batch processing and online serving read the same tables, new findings enter the online retrieval set without an ETL hop.

What we are shipping

We are building two product families on the same foundation.

• OceanBase Database remains our distributed database for mission-critical transaction processing and real-time analytics.
• OceanBase AI Lakebase combines the Lakebase engine with DataStudio for data engineering and governance, and DataPilot as the data intelligence agent.

DataPilot's differentiator is **cold-start accuracy** — how well it answers before anyone hand-tunes it to a specific customer's data. Across POCs in finance, transportation, and other industries, that has come out well ahead of comparable products, for one structural reason: the OSI context underneath it is generated from and lives alongside the data, rather than being reconstructed manually after the fact.

Fifteen years of unification laid the groundwork for this architecture. OceanBase AI Lakebase is the next step built on that foundation. That is where the next stage of the architecture begins.