OceanBase Bets on Lakehouse Integration, AI Databases Enter the Era of Unified Architecture

On June 29, OceanBase officially played a new card: a lake-database integrated AI database architecture. This is not a routine version iteration; rather, it brings together several longstanding debates in the database community—should lakes and warehouses be merged, should AI applications have separate vector databases, can OLTP and OLAP still fit into a single engine—and puts forward one definitive answer: merge them all, with one unified technology stack.

For developers, this move sends a signal that is more substantial than any conference slogan. It means OceanBase is no longer just eyeing MySQL’s position; it’s also going after the territory of Databricks, Snowflake, and a host of vector databases.

Why Propose “Lake-Database Integration” Now

If we rewind one year, the mainstream term in the industry was still “Lakehouse.” Databricks made a name with Delta Lake, Snowflake began embracing Iceberg. The idea was to combine the low-cost storage of data lakes with the analytic power of data warehouses, solving the issue of fragmented enterprise data scattered across S3, HDFS, and data warehouses.

But once Agent applications came along, that combination suddenly proved insufficient.

A typical enterprise-grade AI Agent must operate across multiple data worlds: read historical orders (OLTP), run user profiling analytics (OLAP), retrieve unstructured documents (vector database), and handle real-time data streams from business systems. The current approach is—one database for OLTP, one warehouse for analytics, cold data in the lake, plus a separate deployment of Milvus or pgvector for vector retrieval, all connected through Kafka and numerous ETL pipelines. Data moves constantly between systems, creating latency, consistency, and cost issues. Even worse, an Agent needs a global view of “this very moment,” not a T+1 report.

OceanBase’s assessment: lakehouse integration solves analytical consolidation, but the real pain point of the AI era is the gap between offline and online data. Therefore, OceanBase pushes its architecture one step forward—using one engine to handle online transactions, offline analytics, lake data access, and vector retrieval simultaneously. Among domestic database vendors, this is a bold move.

How Exactly Is the Tech Stack “Integrated”

Putting all four workloads into one engine might sound like marketing jargon, but OceanBase’s path is traceable. The system originated as distributed HTAP, sharing one LSM-Tree storage engine for both OLTP and OLAP, using replica-level read/write separation so analytics don’t hurt transactional performance. That’s the old foundation.

The new developments lie mainly in two areas:

1. Native support for open table formats. Under the lake-database integrated architecture, OceanBase can directly read and write open table formats such as Iceberg and Paimon, treating Parquet files on S3 or OSS as external tables—no need to import them first. This step is crucial: enterprises don’t have to rebuild existing data lakes; OceanBase becomes the access gateway, not another data silo.

2. Deep integration of vector capabilities. Last November, OceanBase open-sourced its AI-native seekdb, featuring hybrid search—combining scalar filtering, full-text, and vector retrieval in one query. The recently released seekdb 1.1.0 adds native macOS support, a Fork Table copy-on-write mechanism, and a capability clearly tailored for AI Coding scenarios: allowing AI assistants to generate SQL against realistic data replicas, verifying them before execution in production. These vector features are now integrated into the main lake-database architecture instead of being a standalone product.

Looking across these layers, OceanBase aims to build a unified data plane:

• Online business writes go through the OLTP path—strongly consistent, low latency
• Analytical queries handled by columnar replicas—no interference with transactions
• Cold data stored as Iceberg tables in object storage—queried on demand
• Embeddings of unstructured data reside in the same system—supporting hybrid retrieval
• Agents access all data through a unified SQL interface

Comparing Databricks, Snowflake, and Vector Databases

The most direct comparison for this architecture is Databricks. Databricks started from Spark, unified lake and warehouse through Delta Lake, and last year acquired MosaicML to bolster its AI capabilities—the route is “analytics first, AI supported.” Its shortfall has always been online transactions—you wouldn’t use Databricks to run a transactional system.

OceanBase takes the opposite route: starting from OLTP and growing upward into analytics and AI capabilities. That difference in starting point shapes their respective target use cases. Industries sensitive to online consistency and latency—finance, telecom, government—are OceanBase’s traditional territory. Lake-database integration gives OceanBase the chance to also cover AI application scenarios for these customers rather than letting them buy Databricks for Agent projects.

Compared with Snowflake, OceanBase’s open-source nature and private deployment options are major advantages in the domestic market. Snowflake’s elegantly decoupled compute-storage architecture rarely lands in China.

Against pure vector databases, the story is even clearer. Products like Milvus and Qdrant focus on “efficient vector search,” but what Agent applications truly need is not pure vector retrieval, but hybrid filtering combining structured conditions + full-text + vector—for example, “find, among users who placed orders over 10,000 in the past 30 days, the 10 whose customer-support tickets are semantically closest to this complaint.” In standalone vector databases, such a query would be assembled in the application layer, with poor efficiency and weak consistency guarantees. OceanBase enables this directly in SQL—with just one statement.

Issues Worth Watching

A polished architecture concept is one thing; real-world implementation is another. Several questions remain unanswered.

Performance trade-offs. Coexistence of OLTP and OLAP is already challenging; adding vector retrieval and lake external-table querying increases complexity. Any workload spike could affect others. OceanBase mitigates with replica isolation and resource groups, but in large-scale production, workload interference remains a top risk.

Depth of Iceberg ecosystem compatibility. The official claim is “supporting open table formats”—but to what extent? Is it read-only or writable? How are transactional isolation levels maintained? Are there pitfalls in interoperability with Spark and Flink ecosystems? These details aren’t revealed at launch; we’ll have to wait for the community version and real-world tests.

True AI nativeness. Seekdb follows an independent open-source path, and community feedback has been positive. But after being merged into the main database, will functionality be reduced? Can the update pace for embeddings, rerank, multimodal search match specialized open-source vector databases? Developers will care deeply about these choices.

Who Will Pay for It

In the short term, OceanBase’s lake-database integration will likely appeal to two customer types.

First, large enterprises already using OceanBase for core business—especially financial institutions and carriers. They possess vast data, have strong data sovereignty requirements, and must launch AI initiatives. Instead of introducing Databricks or deploying separate vector clusters, enhancing the existing database is simpler. Scenarios like intelligent customer support for banks or complaint analysis for carriers naturally fit this architecture.

Second, mid-sized to large enterprises migrating from traditional Oracle/MySQL setups to cloud-native databases while planning an AI data platform. Their biggest fear is fragmented technology choices—one system for OLTP, one platform for analytics, another for vectors—raising operational and synchronization complexity. A unified platform covering most needs, even if not best-in-class on every capability, may still be more cost-efficient overall.

As for individual developers and small teams, the open-source seekdb remains the more suitable entry point, since the full lake-database integrated stack mainly targets enterprise deployments.

An Observation

One of the most interesting trends in the database sector in recent years is that everyone is converging toward the middle—OLTP vendors adding analytics, analytics vendors adding AI, vector databases adding structured capabilities. OceanBase’s new reveal essentially places a public bet on this “grand unification” path.

Whether that path succeeds depends on engineering execution and ecosystem growth, not on a press conference. But the direction is worth noting—because the demands of the Agent era on enterprise data platforms differ fundamentally from those of the traditional reporting era. Data is no longer just queried; it is actively read, written, composed, and reasoned with by Agents. In such scenarios, reducing system hops and shortening the path from data to intelligence becomes the key competitive advantage.

OceanBase is betting on that direction. Whether others follow suit—or a more revolutionary architecture emerges—will become clear in the coming year.

References

Currently, detailed technical documentation is limited. It is recommended to follow OceanBase’s official tech blog and upcoming community releases for practical implementation details and performance data on the lake-database integrated architecture.