Multimodel Tables: One Table for Every Modality Your Agent Needs

For years, OceanBase has evolved toward a unified database — supporting an increasingly broad range of workloads and data, from distributed transaction processing for mission-critical systems to HTAP, multi-model data, and hybrid search.

OceanBase Lakebase marks a deeper shift. The evolution is no longer just about what the database can process, but also about who it serves. Traditionally, databases were designed for developers, DBAs, and applications. In the AI era, they must also serve a fundamentally new kind of user: the agent.

This is what defines an AI database. It is not simply a database that supports images, PDFs, or vectors. It is a database designed to provide agents with the complete, timely, and trustworthy context they need to reason and act.

That leads to the first major challenge: the agent's data dilemma.

The Agent's Data Problem

When a PDF gets updated but its embedding still points to the old version, the agent will answer confidently — and wrong. And you won't know it's wrong.

This isn't a "store more data types" problem. It's a governance problem: when multimodel data enters the critical path, someone has to guarantee version consistency, computation completeness, traceability, and trust. Today, that "someone" is a pipeline your team owns, debugs, and rewrites every quarter.

The multimodel table is OceanBase's answer. It is the core data management capability inside OceanBase Lakebase, and it manages multimodel data — images, audio/video, PDFs, web snapshots, vectors, JSON, and structured fields — as first-class database objects, under one system that provides transactions, consistency, high availability, hybrid search, analytical computation, and online serving.

The rest of this post walks through why agent workloads demand this, and how the multimodel table delivers it.

Why Agents Demand a New Data Model

Agent-facing business objects are inherently multimodel. Inputs might be natural language, images, PDFs, web pages, tables, or business context. At runtime, an agent depends on user memory, knowledge bases, RAG results, structured business data, semantic profiles, and model inference intermediates.

Four shifts follow from this:

1. Unstructured data enters the critical path. It is no longer an attachment sitting in object storage — it is a key input to the agent's decision.
2. Access becomes hybrid search. A single request may combine structured filters, full-text retrieval, vector recall, and analytical aggregation.
3. Real-time requirements spike. Agents run 24/7. T+1 reporting can't keep up.
4. Features are dynamically generated. Many fields aren't written directly — they're extracted asynchronously by models from raw multimodel data.

So the real question is: how do you unify raw multimodel data, structured fields, dynamically derived features, and async computation results inside one database — and make them jointly serve online transactions, analytics, and hybrid search, without giving up consistency or visibility?

That is the design problem the multimodel table solves.

Core Capabilities

Unified Management of Multimodel Objects

Multimodel tables bring multimodel data under the database's transaction and version management system. Large objects — images, audio/video, PDFs, web snapshots — support three storage modes:

Where the object physically sits matters less than what the database guarantees about it: a stable identifier, an access address, a version, a visibility state, and a transaction boundary.

This is what ensures a raw object and its derived features — summaries, labels, embeddings, risk scores — always correspond to the same data version. The "object updated, features still pointing to old content" bug simply cannot happen.

Dynamic Feature Columns

Multimodel data is rich-modal: the same raw object can yield an open-ended set of semantic, structural, quality, and business features. Text produces topics, summaries, embeddings, safety labels, language types, and quality scores. Images accumulate OCR results, tags, risk scores, and business features. The list grows with every new model.

Under a traditional schema, every new feature requires a DDL. Every DDL triggers cache invalidation, write amplification, and background compaction pressure. Feature velocity dies under table-lock latency.

Multimodel tables use a lightweight dynamic column mechanism. Feature extension needs no schema change — while queries stay SQL-native, analytical optimization still applies, and hybrid search still hits an index.

This isn't a fallback to key-value. Key-value is flexible but blind to SQL analysis and search optimization. The multimodel table makes an explicit engineering trade-off between structured optimizability and dynamic extensibility, and refuses to give up either one.

Async Near-Real-Time Computation

Many columns in a multimodel table aren't written by users. They're generated by computation tasks — embeddings, summaries, OCR, quality scores, full-text indexes, vector indexes — powered by built-in model capabilities, background jobs, or external pipelines.

Model inference typically takes hundreds of milliseconds to seconds. That is too slow to block an online write. So the multimodel table doesn't.

1. Raw data commits first. Online write latency stays intact.
2. Background tasks fire feature extraction, index construction, and backfill based on lineage.
3. Derived data becomes visible within a near-real-time window.
4. Reads always land on a consistent snapshot.

The design judgment here is direct: strong synchronization across every derived column is impractical and unnecessary. The right trade-off is a controllable balance between latency, throughput, storage efficiency, and consistency. Computation tasks generate the values. The multimodel table makes those values governable, searchable, analyzable, and consistently readable.

Column-Group Consistency

Async computation creates a new visibility problem. Once a row is written, feature A, feature B, embeddings, full-text indexes, and quality labels may finish at different times, from different tasks, using different models.

A query that sees feature B done but feature A pending will silently produce wrong results.

Column-group consistency fixes this at the storage layer. A business column group only forms a new visible snapshot once every related derived column has completed. Queries and hybrid search always read a consistency snapshot. They never see half-finished data.

Storage-Compute Separation with Hot-Cold Integration

Multimodel data grows without a ceiling — documents, images, video, vectors, derived features. Keeping everything as hot online data is not viable at scale.

Multimodel tables sit on a disaggregated storage-compute architecture with shared storage, and treat hot and cold as one continuum:

• Recent data (e.g., within 90 days) stays cached on SSD for low-latency access.
• Historical data (e.g., beyond 90 days) settles to low-cost shared storage — still queryable, searchable, and analyzable through the same interface.

Users never switch systems to hit cold data. They never stitch between an online database, object storage, and an offline warehouse to answer one question. One view, one query surface, one governance model.

Lineage and Unified Catalog

Which text segment generated that embedding? Which audit model produced that safety label? Which PDF version does that summary correspond to?

Without lineage, the system cannot decide whether a piece of data is complete, trustworthy, or ready to serve. And without that decision, agents ship wrong answers.

Lineage and the Unified Catalog are the metadata backbone of the multimodel table. They record the relationships between raw objects, structured fields, dynamic feature columns, model tasks, versions, and permissions. This metadata powers three things:

1. Triggering. Background tasks fire feature extraction, index construction, and backfill automatically based on lineage.
2. Completeness. The system decides whether a column group or snapshot is fully computed before advancing visibility.
3. Traceability. When an agent produces an answer, you can trace it back to the raw documents, images, records, and derived features it relied on.

Unified Access: Transactions, Analytics, and Hybrid Search

A multimodel table is not a storage structure. It is the shared foundation for three workload types on the same data:

• Online transactions: business writes, ACID, high availability.
• Analytics: large-scale scans, aggregations, filters, joins, feature analysis.
• Hybrid search: structured filters + full-text retrieval + vector recall + tag filtering + business ranking.

Agent access patterns are inherently multi-step. A single request may filter by structured conditions, then search descriptions by full-text, then find similar content by vector recall, then rank by tags, quality, time, and permissions. No single specialized engine covers all four.

The core trade-off is near-real-time over strong synchronization. Search and analytics don't need derived features to complete inside the write transaction — but they do need to become visible within a short, bounded window, and they need to read a consistent snapshot when they do. That is exactly what the multimodel table delivers, and it is what lets one table serve online writes, hybrid retrieval, and analytics without the three-copy stitching tax.

What This Eliminates

If you're building an agent today, the multimodel table replaces the following stack:

The old trade-off between multimodel breadth and database-grade governance is gone.

Where Multimodel Tables Help

Why This Matters

The problem multimodel tables solve isn't whether an AI database can store images, PDFs, or vectors. It's what happens when agents become a first-class user of the database.

If the answer is "another isolated system per data type," you get more surface area to secure, more pipelines to break, and more silent data drift. If the answer is "one governed table that treats every modality as a first-class object," you get an actual data foundation — not a scaffolding of pipelines pretending to be one.

Multimodel tables are that answer. They unify structured data, unstructured data, AI-derived features, and business semantics under one transaction, governance, and computation system. In the past, databases unified data. In the AI era, databases need to unify data, semantics, and the operations that produce them. Multimodel tables are the first step OceanBase Lakebase takes toward that goal.

How to Get Started

Multimodel tables ship as part of OceanBase Lakebase. To evaluate them on your own agent workload:

1. Visit the OceanBase AI Database page for the full Lakebase overview and capability details.
2. Fill out the contact form on the same page with a short note about your workload — the data types you need to manage, the agent scenario you're building, and any performance or governance requirements you already have in mind.
3. Our team will reach out to walk you through a preview environment, help you model your first multimodel table, and compare it against the stack you're replacing.

If it helps the agent stop shipping wrong answers, it helped.