OceanBase Hours Singapore: Why the Database Is Becoming the Foundation of the AI Data Platform

AI Doesn’t Just Need More Data. It Needs Fresher Data.

At OceanBase Hours in Singapore this week, the conversation kept circling back to one uncomfortable fact for enterprise data teams: the old rules of data freshness don’t hold once AI agents are the ones reading the data.

A dashboard that’s a few hours stale is a minor inconvenience for a human. A payment or risk-control agent acting on an account balance that’s a few seconds stale can make the wrong call entirely, sometimes with real financial consequence.

That distinction sat at the center of a panel discussion featuring OceanBase CTO Charlie Yang and Forrester Principal Analyst Indranil Bandyopadhyay, who spent 14 years as a CIO before moving into analyst work. Their exchange, part of the OceanBase Hours series, mapped out where enterprise data infrastructure is heading as AI moves from pilot projects into production systems, and offered a useful lens for a question a lot of data teams are now asking: is the database itself becoming AI infrastructure.

Four Kinds of Convergence

Bandyopadhyay framed the shift around a single word: convergence. Not as a buzzword, but as a description of four separate boundaries that are dissolving at once inside modern data platforms.

Data models are converging. Enterprises used to accept separate engines for relational data, documents, and vectors, copying data between them as needed. That’s giving way to a multimodel core, where relational facts, documents, relationships, and embeddings live under one set of transactional controls, because agentic AI often needs several of these data types within a single interaction.

Transactions and analytics are converging, into what Forrester calls “translytical” architecture. Every copy of data carries an age, and every hop through a pipeline adds to it. An agent approving a transaction off a two-second-old account balance can make the wrong decision or create friction that didn’t need to exist. Keeping transactional and analytical workloads on live data, rather than a downstream copy, removes that lag.

Governance is converging into the data layer itself. Traditional access control assumes a human who authenticates occasionally and predictably. Agents act continuously and concurrently, often in ways nobody explicitly scripted. Bandyopadhyay argued governance can no longer sit bolted on top of or beside the database; an agent’s identity, purpose, and the relevant policy need to be evaluated inside the engine, at the moment data is touched.

The query surface is converging, toward something closer to a single interface, typically SQL, that can reach across relational data, JSON, time-series, geospatial, and vector data without forcing an agent to juggle a different query language for each.

Yang’s addition to the framework was pointed: real-time capability, not just cost savings, may be the more important benefit of convergence, and it’s the harder one to retrofit. “The value is not about putting everything into one place to save cost,” he said. “It’s about making sure the freshest data lives in the same system where an agent asks the question.”

Two Companies, Same Destination, Different Starting Points

The panel’s most useful framing, for anyone trying to place OceanBase in the market, was Yang’s observation that vendors are converging on similar architecture from opposite directions.

Databricks built its position from the data lake outward. Starting with Apache Spark and the Lakehouse architecture, it unified data engineering, analytics, and machine learning, and is now extending toward transactional and application-serving capabilities. Its Lakebase product runs PostgreSQL compute against externalized, distributed storage, keeping compute stateless and elastically scalable. Its proposed LTAP (Lakebase Transactional-Analytical Processing) architecture goes further, unifying transactional and analytical data at the storage layer: PostgreSQL for transactions, Lakehouse engines for analytics, both reading one durable copy of open columnar data.

OceanBase’s route runs the opposite way. It was built first as a shared-nothing distributed database for mission-critical transactions, hardened over more than a decade inside Ant Group’s financial infrastructure, including handling roughly half a million transactions per second during peak events like Singles’ Day. From that transactional foundation, OceanBase added HTAP, letting real-time analytics run against live operational data without a separate copy. It’s now extending that same architecture again through Lakebase, its term for a unified engine bringing in open storage, multimodal data management, hybrid search, and AI processing, layered with a semantic context layer made up of two additional products: DataStudio, for data engineers building governance and business context, and DataPilot, which translates natural-language questions into queries using enterprise ontology.

Put simply: Databricks is bringing real-time transactions to the lake. OceanBase is bringing lake and AI capabilities to a database built for transactions. The symmetry is worth sitting with - two companies arriving at similar architecture from opposite starting points says something about where the market believes AI data infrastructure is headed.

The Multimodel vs. Multimodal Distinction

One area where OceanBase and Databricks visibly diverge is how each handles the sprawl of data types a modern AI application actually touches, structured order records sitting next to chat transcripts, images, PDFs, and vector embeddings, all describing the same underlying business entity.

Databricks coordinates this through Delta tables, Unity Catalog, file storage, and Mosaic AI Vector Search, building indexes from Delta tables and combining vector similarity, keyword search, and filtering inside its governance framework.

OceanBase takes a table-centric approach: structured fields, JSON, documents, images, audio, video, vectors, and model outputs can be managed under the semantics of a single table, sharing metadata, access controls, lifecycle policies, and query interfaces even when the underlying physical storage differs.

The distinction worth understanding here isn’t which platform can technically store an image or a vector, most can. It’s whether that multimodal data inherits database-grade transactional guarantees, consistency, and real-time serving, or sits alongside them as a separately maintained system.

Why Buyers Shouldn’t Buy on AI Alone

The most practical part of the discussion had nothing to do with architecture. Both speakers, independently, warned against buying a data platform on the strength of an AI use case alone.

Bandyopadhyay’s advice: choose a platform for the workloads already running today, keep AI in mind, but don’t walk into a CFO conversation asking for budget purely on the promise of agentic AI. Measurable AI ROI is still hard to demonstrate across the industry, and that pushback is real.

Yang built directly on the point, offering three practical filters for a first project: find a real business pain point with an actual owner waiting for the result, not just a technical justification; pick either a genuinely new AI-native application with nothing to migrate, or an existing analytical workload being converted to natural-language, agent-driven analytics, rather than attempting a full legacy migration up front; and start with high-value data, not all of it. He pointed to an internal Alipay example where less than 5% of total data, migrated onto the new platform, ended up serving more than 90% of hot queries, with the remaining cold data left untouched in the legacy system with no ill effect.

Bandyopadhyay closed the session with a line built to be quoted: “Converge where the seams cost you, and specialize where scale demands it.”

The Market Context

OceanBase’s push into AI data infrastructure is also a capital markets story. The company, spun out of Ant Group’s internal database work and now bolstering its independence with its own board and employee share programme since 2024, has reportedly been in discussions to raise between 2 billion and 3 billion yuan in Series A funding to fund its AI expansion, according to a Bloomberg report citing people familiar with the matter. The same report noted OceanBase’s annualized revenue topped US$200 million in 2026, up roughly 70% year over year, with a client base concentrated in China but expanding into Southeast Asia, Japan, India, and Latin America, and that the company is explicitly using Databricks, now seeking capital at a reported $188 billion valuation, as a benchmark for where it wants to go.

Whether OceanBase becomes “the next Databricks” is a question the market, not a single event, will answer. But the architectural direction on display in Singapore this week, combined with its proven track record in mission-critical transactions, suggests it is running the same playbook from a different starting point - and in the AI agent era, that starting point may matter more than ever.