From Vibe Coding to AI Agents — OceanBase seekdb Builds a Millisecond-Level Data Sandbox for the AI Era

Posted on In Views: Word count in article: 2k Reading time ≈ 7 mins.
OceanBase seekdb 1.1.0 introduces the Fork Table feature. Based on copy-on-write and consistent snapshots, it creates logically independent, read-write-isolated data branches in milliseconds, making data as branchable and rollbackable as Git — powering AI scenarios such as Vibe Coding, A/B testing, and multi-agent systems.

Manage your data like Git, and reshape the data workflow of the AI era

🌟 Tip: The seekdb used in this article is the AI-native database open-sourced by OceanBase. You are welcome to try it out at https://github.com/oceanbase/seekdb — it should bring a cleaner, more efficient data management solution to your AI application development!

From Vibe Coding to AI Agents — OceanBase seekdb Builds a Millisecond-Level Data Sandbox for the AI Era

Introduction

In today’s world, sweeping in with LLMs and AI-native development, the data workflow is quietly undergoing a silent crisis. Data scientists try to validate three different feature-engineering approaches simultaneously on a single production dataset; development teams need to run A/B tests on a live recommendation table to evaluate two brand-new algorithmic strategies; and in Vibe Coding practice, the data changes that AI agents automatically generate and need to validate keep emerging endlessly.

These scenarios all point to a common need: we need to quickly and cheaply create multiple fully isolated “experiment sandboxes” based on the same dataset.

Yet traditional data management approaches reveal their cumbersome nature at this very moment. Whether using CREATE TABLE ... AS SELECT ... for a full copy, or relying on ETL tools to export and re-import, when facing data tables at the GB or even TB scale, it means waiting for hours or even days, and storage costs multiplying. This model not only stifles the possibility of rapid iteration, but also reduces “data version management” to empty talk. The reason Chroma’s collection fork and Neon’s branch features have drawn so much attention is precisely that they hit this pain point of the era squarely on — providing data with lightweight, instant copy and isolation capabilities, just like Git branches.

It is against this backdrop that OceanBase seekdb 1.1.0 brings the all-new Fork Table feature. It is not mere syntactic sugar, but a shift in design philosophy: tables should not merely be copied — they should be “branched.” It aims to let data teams instantly branch out at a near-zero cost from a given consistent snapshot point, creating data branches that can evolve independently and run experiments in parallel, thereby seamlessly meeting the LLM era’s extreme demands for data iteration speed and collaboration models.

From Vibe Coding to AI Agents — OceanBase seekdb Builds a Millisecond-Level Data Sandbox for the AI Era

Core Capability: Creating Data Branches in Milliseconds

Fork Table lets you instantly create a logically independent, fully read-write-isolated target table based on a consistent snapshot of the source table at a given moment, through a single simple SQL statement.

1
FORK TABLE t1 TO t1_fork;

Fundamentally, this feature natively implements “data table branching” at the database level. From the moment of its birth, this newly created branch table has an independent identity and full table capabilities. Users can perform any operation on it that is allowed on an ordinary table. Most importantly, all these operations are strictly confined within this branch environment and do not affect the source table that created it.

Core Characteristics of Fork Table

1. Snapshot consistency: The branch is frozen at the data state of the moment it was created; subsequent changes to the source table are invisible to it.

2. Full read-write isolation: Each branch is an independent sandbox where any experiment can be safely conducted.

3. Progressive availability: The branch is immediately usable, with data construction completed asynchronously in the background, transparently to the user.

Therefore, Fork Table is more than just an optimized copy command. It is a foundational capability designed to transform the data workflow. By tightly combining the three characteristics of “snapshot, isolation, and progressive availability,” it provides native branch and version management support for data assets, directly addressing the urgent demands of modern data-intensive applications for agility, isolation, and parallel experimentation.

From Vibe Coding to AI Agents — OceanBase seekdb Builds a Millisecond-Level Data Sandbox for the AI Era

Technical Principle: Copy-on-Write Working Hand in Hand With Snapshot Isolation

The core of Fork Table achieving millisecond-level data branching lies in the elegant combination of the “Copy-on-Write” strategy with consistent snapshots. This design fundamentally changes the traditional way of copying data: instead of performing a full physical copy, it achieves efficient data version management through “logical references” and “progressive data construction.”

From Vibe Coding to AI Agents — OceanBase seekdb Builds a Millisecond-Level Data Sandbox for the AI Era

The entire branch creation process is divided into two coordinated phases: foreground creation of branch metadata and background progressive data construction:

  • When a Fork Table operation is executed, the foreground first locks a globally consistent point in time — fork_snapshot_scn, and this value becomes the “moment of birth” of this branch. The system then merely copies the source table’s structure definition and necessary metadata, establishes an independent logical identity for the target table, and records in its metadata the reference relationship to the source table and the snapshot point — that is, the ForkTabletInfo shown in the figure above. This process involves only a minimal amount of metadata operations, and therefore can be completed within hundreds of milliseconds. The new table is immediately queryable, and the database engine locates the source table’s data layer through the reference relationship in the metadata and strictly applies fork_snapshot_scn for filtering, ensuring that the returned data view corresponds exactly to the snapshot at the moment the branch was created.
  • While the foreground responds to the user, the background DDL task begins data construction. The clever part here is: reuse the source table’s data as much as possible rather than copying it. The reason this can be designed this way is that OceanBase seekdb’s LSM-based storage architecture inherently guarantees that persisted data is not updated in place, which makes it possible to safely share data blocks at a specific point in time. During data construction, decisions are made based on fork_snapshot_scn: for SSTables that were fully “frozen” before the snapshot point, only the reference count of their underlying data blocks (Macro Blocks) is incremented, achieving zero-storage-cost cross-table sharing; for SSTables that mix old and new versions, a snapshot iterator extracts the data visible at the snapshot point and rewrites it into a new SSTable file.
  • Data isolation is ensured at two levels. Logical isolation is guaranteed by fork_snapshot_scn as an absolute dividing point — whether for foreground queries or background construction, the system strictly partitions data ownership by this snapshot point. Physical isolation is naturally achieved through copy-on-write and the database’s inherent Compaction process: new writes on the branch go into its private storage area; over time, the system, like cell division, gradually reduces the shared data blocks, ultimately completing a full separation of storage.

From Vibe Coding to AI Agents — OceanBase seekdb Builds a Millisecond-Level Data Sandbox for the AI Era

Applicable Scenarios: From Vibe Coding to Multi-Agent Systems

Scenario 1: A “Time Machine” for Vibe Coding

In the Vibe Coding mode where AI generates and executes SQL, errors are inevitable. Fork Table can automatically create a snapshot before every major change. Once the AI’s modification introduces a problem, you can roll the table back to any healthy snapshot with one click, just like switching branches in Git — achieving “bold experimentation, worry-free rollback.”

Scenario 2: A “Parallel Experiment Field” for A/B Testing

Based on the production master table, instantly create independent branches for different strategies (such as Prompt A/B). Each experiment runs fairly in an environment with the same data source and full isolation, with results that don’t interfere with one another, dramatically shortening the path from “idea” to “conclusion.”

Scenario 3: A “Data Version Lock” for Model Training

After feature engineering is complete, fork a versioned snapshot table (such as features_v1.2). All subsequent model training reads from this fixed table, ensuring full reproducibility of experiments and rooting out the “paper alchemy” problem caused by changes in the underlying data.

Scenario 4: An “Independent Workroom” for AI Agents

In a multi-agent system, you can fork a private branch of the master knowledge base for each Agent. The Agent learns, records, and experiments within it, avoiding cross-contamination of memory, and the valuable knowledge it produces can be carefully merged back into the master base.

From Vibe Coding to AI Agents — OceanBase seekdb Builds a Millisecond-Level Data Sandbox for the AI Era

Getting Started Quickly: Multi-Language Interfaces and Best Practices

The practice is extremely simple — whether in SQL, Python, or other languages, you can easily use the Fork Table feature.

SQL Interface: The Most Direct Way

1
2
3
4
5
6
7
8
9
10
11
12
13
-- 1) Create a branch version based on the main version (the data baseline is the snapshot at fork time)
FORK TABLE t1 TO t1_branch_v2;

-- 2) Make experimental changes on the branch (e.g. data revisions / feature updates / index and metadata policy adjustments)
-- ... run DML / business workflows against t1_branch_v2 ...

-- 3a) Quick rollback: stop using the branch version and return to the main version
-- (the switching method follows your business and ops process; e.g. revoke routing to the branch version and clean up the branch table)
DROP TABLE t1_branch_v2;

-- 3b) Promotion: make the branch version the new default version (e.g. switch via an atomic rename)
-- RENAME TABLE t1 TO t1_branch_backup, t1_branch_v2 TO t1;
-- DROP TABLE t1_branch_backup;

Python Interface: Collection.fork in pyseekdb

1
2
3
4
5
6
from pyseekdb import Collection

collection = Collection("production_data")
# Create a branch
forked_coll = collection.fork(name="experiment")
# Operate on the branch...

JavaScript Interface: Collection.fork in seekdb.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import { SeekdbClient } from "seekdb";

const client = new SeekdbClient({
  host: "127.0.0.1",
  port: 2881,
  user: "root",
  password: "",
  database: "test",
});

const collection = await client.getCollection({name: 'my_collection'});
// Create a branch
const forkCollection = await collection.fork('fork_collection');
// Operate on the branch...

Best Practices

  1. Manage the branch lifecycle sensibly: promptly clean up experiment branches you no longer use to avoid storage fragmentation;
  2. Monitor the number of branches: although each branch has a low initial cost, too many branches may affect overall management efficiency;
  3. Use branch labels: add descriptive labels to important branches for easier lookup and management later.

Try it now: Visit the OceanBase seekdb official documentation to learn more usage and technical details.

From Vibe Coding to AI Agents — OceanBase seekdb Builds a Millisecond-Level Data Sandbox for the AI Era

Next Stop: Fork Database

The release of Fork Table is the first cornerstone OceanBase seekdb has laid in response to the data-agility challenges of the AI era. For the first time, at the database kernel level, it endows single-table data with native, millisecond-level, Git-style branching capabilities, making isolated experimentation and safe iteration standard operations in the data workflow.

And this is only the beginning. Next, we will extend this paradigm to the entire database: Fork Database is coming soon.

Through a simple command such as FORK DATABASE prod TO staging;, you can clone an entire database and all its objects in milliseconds based on a globally consistent point in time. This will truly achieve:

  • Environment as code: Instantly replicate the production environment for development, testing, and staging, greatly improving R&D and operations efficiency.
  • Business-level rollback: With the database as the atomic unit of operation, achieve a consistent snapshot across multiple tables and one-click recovery, providing reliable assurance for complex business changes.
  • Secure data sharing: Rapidly generate complete and isolated database copies to support auditing, analysis, and collaboration, releasing data’s value while ensuring the master database’s stability and security.

The evolution of branching capabilities from Table to Database marks OceanBase seekdb systematically building the agile paradigm of “data versioning” and “isolated collaboration” from a single-table feature into database-level infrastructure. We firmly believe that versioned branching and collaboration of data will, just like version control of code, become a core development paradigm for future data-intensive applications.

OceanBase seekdb will continue to deepen its work here, so that every developer can manage continuously evolving data as easily, confidently, and efficiently as they manage code. From branching a single table to cloning an entire database, we are jointly building the innovative foundation on which the next generation of AI-native applications depends.

The waves have risen; the future has arrived.

Further Reading