In the AI Era, Why Did OceanBase Open Source an AI-Native Database Like seekdb?
Editor’s note:
On November 18, the 2025 OceanBase Annual Conference was held in Beijing, where OceanBase’s first AI-native hybrid search database, seekdb, was unveiled and open sourced.
Feng Zhongyan, General Manager of OceanBase’s Open Source Ecosystem (alias: Ji Junxiang—better known as “Lao Ji,” the host of the WeChat account “Lao Ji’s Tech Talk”), will introduce in this article the reasoning behind OceanBase’s decision to open source seekdb.
If you are interested in seekdb (the AI Native Database) mentioned in this article, you are welcome to try it out at https://github.com/oceanbase/seekdb. We believe it will bring fresh inspiration to your AI application development!
At the 2025 OceanBase Annual Conference, we officially unveiled and open sourced OceanBase’s first AI-native hybrid search database, OceanBase seekdb (seekdb for short).
After the launch, many friends in the community kept asking three questions:
1. Why open source seekdb?
2. How does it differ in positioning from OceanBase?
3. Is this open source effort here for the long haul?
I’d like to use this article to answer these three questions in a systematic way. But before that, it’s worth revisiting a more fundamental question: why did OceanBase choose the open source path in the first place?
Looking Back: OceanBase’s Open Source Journey
Open Source Is a Strategic Choice, Not a Tactical Move
When OceanBase announced its open source plans in June 2021, the most common question from the outside world was: why would a database product that had already achieved commercial success choose to go open source?
Our judgment at the time was this: a database is infrastructure, and infrastructure must evolve together with its users and ecosystem. This is not just empty rhetoric. The unique nature of infrastructure software is that its value depends not only on the technical sophistication of the technology itself, but even more on the completeness of its ecosystem and the trust of its users. And open source is the most direct and effective way to build that trust.
From day one, OceanBase treated open source as a company-level strategy. In terms of resource investment, OceanBase’s commitment to its open source project has been enormous—from R&D to operations, it has received the best resource allocation available.
From Kernel to Complete Solution
In the early days of going open source, we only released the kernel and the installer. Users quickly gave us feedback: what they needed was a complete solution, not a single technical component.
Within six months of going open source, this feedback prompted us to release core tools such as OMS, OCP, and ODC in succession. These efforts all served a single goal: to lower the barrier to entry so that more people could actually put the database to use.
Improving usability is a continuous engineering effort. Just like optimizing the database kernel, it has no finish line—only an ongoing process of getting ever closer to user expectations.
A Key Evolution in the Open Source Strategy: Unifying the Code Branches
About a year into going open source, we ran into a serious engineering problem: synchronizing code between the Community Edition and the Enterprise Edition.
In the OceanBase 3.X era, the two editions lived on separate code branches maintained by different teams. This architecture led to substantial synchronization costs and potential feature discrepancies. Users would frequently encounter situations where a bug already fixed in the Community Edition still existed in the Enterprise Edition.
By the 4.X era, we made an important technical decision: merge the Community Edition and the Enterprise Edition onto the same code branch, using compilation macros to distinguish between the different releases. To achieve this, we invested heavily in R&D resources to modularize the codebase. Although the investment was significant, it sent a clear signal to the community—our commitment to open source is real and long-term.
Four Years of Results: Validation at Scale
To date, OceanBase has been open source for four years, with deployments surpassing 100,000 instances and more than 2,000 enterprise users. Looking at the growth curve: 6,000 instances two years ago, 30,000 last year, and over 100,000 this year—an exponential growth trajectory.
In the domestic database space, apart from the PostgreSQL and MySQL ecosystems, the OceanBase community is the largest. This set of numbers shows that the open source strategy has been validated by the market.
But growth in scale does not mean challenges have disappeared. On the contrary, the biggest challenge is now arriving.
The Underlying Logic of AI Reshaping Infrastructure
GenAI: Not a Tool Upgrade, but a Generational Shift in Infrastructure
Consider one set of figures: 17 months after the launch of ChatGPT, its monthly active users surpassed 800 million, and its annual query volume reached 5.5 times that of Google.
The significance of these numbers lies not in the success of any single product, but in the trend they reveal: GenAI is becoming the core of a new generation of infrastructure. This is not an incremental upgrade at the tool level—it is a generational shift across the entire technology stack.
What does this mean for databases? It means we must rethink the core value proposition of the database.
AI Applications: From Proof of Concept to Large-Scale Adoption
The large-scale adoption of AI must ultimately be realized through applications. Only applications can translate the capabilities of AI into end-to-end productivity gains.
Take AI Coding as an example. Developers who have used these tools share a common feeling: these are two completely different worlds. This discontinuity in experience is the most intuitive embodiment of the value of AI applications.
The Threefold Challenge AI Poses to Databases
Looking across the technology leaders in the global AI database space, you’ll find they are all responding to three shared challenges: the fusion of data, the fusion of models, and rapid responsiveness to developers.
These three directions form the core proposition of how databases will evolve in the AI era. OceanBase’s answer is seekdb.
OceanBase’s Answer to the Data Challenges of the AI Era: seekdb
seekdb is positioned as an AI-native hybrid search database. Understanding this positioning requires exploring it across three dimensions.
Data Fusion: Multimodal Storage and Hybrid Search
Where the Real Demand Comes From
The demand for data fusion stems from the genuine evolution of business scenarios, not from the self-imagining of a technical team.
We’ve had in-depth discussions with several large-scale internal business teams—businesses like DingTalk and Fliggy, each with over a hundred million daily active users and data volumes at the petabyte scale. These businesses sit at the cutting edge of technology adoption, and the problems they encounter often foreshadow the challenges the entire industry is about to face.
Take Fliggy as an example. In their vector search scenarios, they encountered a classic problem: pure vector similarity retrieval fell short of their business needs. They needed to assign weights to each row of scalar data and implement complex Trigger logic to dynamically adjust search strategies. In short, vector retrieval had to be tightly integrated with precise structured-data filtering to deliver results with real business value.
This is not an isolated case. As RAG and search scenarios enter deeper waters, almost every team runs into similar problems.
From a Single Index to Hybrid Retrieval
The design assumption of traditional databases is that different types of data use different indexes, each relatively independent of the others. Full-text indexes handle text, B+ tree indexes handle structured data, and each does its own job.
But AI-era data usage breaks this assumption. A typical AI application query may involve several operations at once: vector similarity matching for semantic understanding, full-text search for keyword matching, structured filtering for constraints like time and location, nested queries over JSON fields, and GIS spatial computation. All these retrieval types must work together within a single query, with unified relevance ranking.
This is the essence of hybrid search: not simply stacking multiple indexes together, but enabling them to achieve genuine fusion at the query layer, producing unified, business-ready results.
The Technical Challenges of the Deep Waters
The technical challenges brought by hybrid search are multidimensional.
The first is the depth of data understanding. When the way the underlying data is used changes, the programming interface must evolve accordingly. Developers need new ways to express complex hybrid query intent, which places high demands on API design.
The second is the complexity of performance optimization. Different types of indexes have different performance characteristics, and finding the optimal execution path within a hybrid query is a complex optimization problem.
The last is consistency guarantees. How do we ensure the transactional consistency of multimodal data? When vector indexes and structured indexes need to be updated at the same time, how do we ensure data integrity?
This Is Only the Beginning
The hybrid retrieval over full-text indexes, vector indexes, JSON, and GIS that we see today is only the starting point of this evolutionary process.
Future data fusion will be deeper and more flexible. Directions we can foresee include: support for more data modalities (native understanding of audio and video), smarter query understanding (automatic conversion from natural language to hybrid queries), and more dynamic indexing strategies (automatic optimization based on query patterns).
This is an intrinsic requirement that the AI era places on databases, and it is the direction in which seekdb will continue to evolve.
Model Fusion: The Technical Path of AI Inside
Observing Industry Trends
Looking at the technology roadmaps of companies like Oracle, Snowflake, and Databricks, you’ll find that AI Inside is becoming an important direction for database infrastructure.
The core idea of so-called AI Inside is to build AI capabilities directly into the database engine, rather than invoking them as external services. This means the database is no longer merely a storage and retrieval system for data, but possesses the ability to understand data, generate data, and reason over data.
Frankly speaking, this field is still in an early exploratory stage. Including the giants mentioned above, everyone is still searching for the optimal technical path. The same is true for OceanBase—seekdb’s AI Inside capabilities have only just begun.
But the certainty of the direction is clear. This is not a question of “whether to do it” but of “how to do it well.”
The Ultimate Experience from the User’s Perspective
The best way to understand the value of AI Inside is to start from the user’s perspective.
What is the experience users truly need? It’s “Document in, Data out”—you input a need described in natural language and directly obtain usable data results. Users should not need to understand the underlying data model, should not need to write complex query statements, and should not need to manually combine multiple API calls.
Here’s a concrete example. Suppose a user wants to query “the product category with the fastest sales growth over the past month, excluding the impact of seasonal factors.” In the traditional model, this query would require: writing a SQL aggregation query, implementing a statistical algorithm for seasonal adjustment, and possibly even calling an external time-series analysis service.
In the ideal AI Inside scenario, the user simply describes their need in natural language. The database’s built-in AI capabilities then automatically understand the query intent, generate an execution plan, invoke built-in statistical analysis, and return the final result.
This is the technical meaning behind the vision of completing a data query in three sentences.
The Technical Substance of AI Inside
Realizing AI Inside requires deep integration across multiple technical layers.
The first is natural language understanding and query generation. The database needs to understand the user’s natural language input and convert it into an executable query plan. This is not simple Text-to-SQL—it requires understanding the business context, handling ambiguous expressions, and supporting multi-turn interaction.
The second is built-in vector computation. Vectors are the core representation of data in the AI era. The database needs to natively support the storage, indexing, and computation of vectors, rather than relying on an external vector database.
The third is localizing model inference. By integrating model inference capabilities into the database engine, we can avoid frequent data transfers between the database and AI services, dramatically reducing latency and improving security.
The fourth is intelligent query optimization. Using AI capabilities to optimize query execution plans, dynamically adjusting strategies based on data distribution and query patterns.
The fifth is data augmentation and generation. The database has the ability to automatically annotate, augment, and even generate data, providing higher-quality data for downstream AI applications.
seekdb’s Technical Roadmap
Deep fusion with models is one of the core technical directions of seekdb.
In the current version, seekdb already has foundational AI Inside capabilities: native vector data types and indexes, built-in Embedding generation, and a simplified natural language query interface.
On the future roadmap, we will continue to strengthen this direction: more powerful natural language understanding, more built-in AI functions, deeper model integration, and smarter automatic optimization.
This is a direction that requires long-term investment, but it is also a core capability that databases must possess in the AI era. The focus of competition is on who can realize it earlier and better.
Lightweight Architecture: Redefining the Developer Experience
Application Developers Decide the Future of Databases
Looking back at history, the emergence of the LAMP stack 20 years ago allowed MySQL to capture nearly the entire database market share of the Chinese internet. The essence of this phenomenon is that application developers determine the direction of database selection.
In traditional scenarios, the core criterion DBAs use to choose a database is maturity and stability. But in the AI era, to win over developers, you must meet their core demands: faster iteration speed, a lower barrier to entry, and a lighter resource footprint.
A Thorough Architectural Overhaul
OceanBase has long aimed to run on just 1 core and a few GB of RAM. Over the past two years, we invested enormous effort into slimming it down, but this goal was never fully realized.
seekdb chose a more thorough path: completely shedding historical baggage and undertaking a bold redesign. We removed complex components such as the distributed architecture, multi-tenancy, RS modules (cluster management), and distributed transactions, dramatically reducing the amount of code.
The end result: OceanBase requires a minimum of 2 cores and 6 GB of resources, while seekdb requires a minimum of only 1 core and 2 GB (in practice you can configure the resource footprint even smaller—feel free to give it a try), supporting second-level startup and embedded deployment. Embedded capability will open up edge-cloud integration scenarios, which have broad application prospects in areas such as IoT.
A Redesign of the Development Experience
We designed a brand-new SDK for seekdb that is more concise than the original Python SDK—three lines of code are enough to complete a basic application. The installation process has also been comprehensively simplified.
A Fundamental Improvement in Iteration Speed
All of the improvements above ultimately point to one core goal: responding to developer needs faster.
OceanBase’s distributed version carries requirements such as financial-grade high availability and strong consistency. These requirements determine its architectural complexity. The most complex module in a database is transaction management, and distributed transactions are the very peak of that complexity—they involve a series of technical challenges such as RPC and large transaction recovery.
After removing these modules, seekdb can achieve truly lightweight iteration, responding quickly to developer feedback and needs.
Open Protocol and Ecosystem Strategy
seekdb adopts the Apache 2.0 license. Compared with other open source licenses, Apache 2.0 is more friendly to all users, and is especially advantageous for expanding into overseas markets. Building the ecosystem is a core strategic direction for seekdb.
Distinguishing the Positioning of seekdb and OceanBase
seekdb’s positioning can be summed up in two keywords: more AI Native, and more lightweight.
The concrete recommendation for selection is this: for scenarios with large data volumes that require distributed capabilities, we recommend OceanBase; for scenarios with lighter data volumes or more AI-oriented needs, we recommend seekdb. seekdb will maintain a faster iteration cadence in the AI direction, meeting the needs of users in this domain more quickly.
Beyond seekdb: Building a Complete Support System for AI Developers
The Three Hottest Directions in AI Applications
The three most active directions in the AI field right now are Agent, RAG, and Memory. Almost all major vendors are making moves in these three directions. For OceanBase, in addition to seekdb itself, we have also made systematic investments in these areas.
PowerRAG: Innovation Standing on the Shoulders of Giants
PowerRAG is a project built on top of RAGFlow as a derivative development. The value of PowerRAG lies in the enterprise-grade enhancements made on this foundation.
The main directions of enhancement include: better enterprise-grade adaptation (features such as high availability and permission management) and rich component and plugin support (such as DeepSeek OCR and MinerU), capabilities that are critical in enterprise-grade RAG scenarios.
PowerMem: Making AI Applications More Token-Efficient
PowerMem is the Memory project we open sourced at the same time. Its core value is significantly reducing the Token consumption of AI applications—compared with OpenAI’s Memory solution, it can save 96% of Tokens.
How is this achieved? Mainly through the following technical means: intelligent memory management, a layered memory architecture, hybrid retrieval based on the seekdb kernel, deep optimization at the Prompt level, and multimodal support. In addition, we are also exploring Graph capabilities to support emerging business scenarios such as AI Inside and hyper-personalization.
seekdb Roadmap: Developers and Ecosystem at the Core
Compared with OceanBase, seekdb will be more focused on developers and the ecosystem. We will actively collaborate with upstream and downstream ecosystem partners, and we especially hope to establish deep partnerships with AI open source projects, leading domestic open source projects, and top global open source projects.
As many friends in the community already know, I’ve spent some time working overseas this year, and next year I expect to devote even more time to globalization. This does not mean a reduction in domestic support—the community team will continue to serve everyone as it always has. At the same time, we will invest more resources in expanding and connecting the global developer ecosystem, making OceanBase more developer-friendly.
I’ve always held one belief: a Chinese database capable of going global must be an excellent product that has been tested by a demanding market. A database that can survive and thrive in a fiercely competitive market like China’s often holds a significant competitive advantage when it enters the global market.
The Future: seekdb’s Room to Grow
Today’s seekdb can be understood as a newborn member of the OceanBase ecosystem. OceanBase has accumulated 15 years of experience and has reached considerable scale and influence. seekdb, by contrast, is just getting started.
But our judgment about the future is that seekdb’s room to grow will be full of possibility.
This judgment is based on two basic facts. First, within the database market, the centralized database market is still very large, which gives us the possibility of expanding into a larger market space. Second, AI is the watershed of the next era, and seekdb has inherited OceanBase’s 15 years of foundational capabilities in reliability, stability, and strong consistency, giving it an innate advantage in the AI direction.
In the future, seekdb will continue to iterate rapidly on the AI track, then continually feed the AI capabilities it accumulates back into OceanBase, better meeting the diverse needs of more enterprise customers in mission-critical workloads, real-time analytics, and AI search.
Conclusion
Let’s return to the three questions we opened with.
Why open source seekdb? Because open source is OceanBase’s core strategy, and a database, as infrastructure, must grow together with its users and ecosystem.
How does seekdb differ in positioning from OceanBase? seekdb is more AI Native and more lightweight, more oriented toward developers in the AI era; OceanBase, through its integrated capabilities, comprehensively meets the diverse needs of enterprise customers in mission-critical workloads, real-time data analytics, and AI search.
Is seekdb’s open source effort long-term? Yes, it is a strategic-level investment. Just as OceanBase is still growing four years after going open source, seekdb will also receive long-term, sustained investment.
Open source is not the finish line, but the starting line. Open sourcing seekdb is OceanBase’s strategic choice for the AI era. We look forward to working with the community to witness seekdb grow from its first steps to maturity.