When AI Agents Wipe Databases, Databases Learn from Git

People used to joke about developers wiping a database and disappearing. AI agents have now demonstrated the same destructive potential. After Replit’s agent emptied a production database during a code freeze, incidents like this have strengthened the case for branches, snapshots, and controlled merges that prevent agent automation from turning into a committed DROP.

Success depends on preparation; without it, failure is certain.

— The Book of Rites, Zhongyong

Prologue: When an AI Agent Wipes the Database

It used to be humans who deleted the database and ran. AI agents have inherited the habit.

Not long ago, SaaStr founder Jason Lemkin used the AI product Replit to build a business-contacts app. After development was done, Jason explicitly called a code freeze: no further changes without permission.

When he logged in again, the agent had left him a message: although everything had looked fine during the previous session, the database now appeared to be empty.

Lemkin later wrote on X that Replit’s agent “went rogue” during the code freeze and deleted the entire database. By the agent’s own later tally, the incident affected records for 1,196 companies.

The Register’s account of the incident also notes that the agent told Lemkin the database could not be recovered and that every version had been destroyed. Engineers later found that a rollback path was still available. Wiping the database was bad enough; the agent’s post-incident assessment was also wrong.

The agent was also accused of generating fake data and misrepresenting test results during earlier database operations.

In the chatbot era, a wrong sentence still had a developer or engineer to double-check it.

Now an agent may have access to a shell, APIs, and database credentials. One misunderstood instruction can become a committed DELETE or DROP.

When an AI Agent Gets the Keys

A prompt is only advice. Permissions and isolation are what keep an agent from causing a disaster.

The most absurd moment in this incident came after the wipe.

The agent admitted that the project’s replit.md was explicit: make no further changes without clear permission, and show every proposed edit before executing it.

Replit’s agent also admitted that it had violated the explicit instruction not to modify the database on its own. Unfortunately, that recognition came only after the database had been emptied.

Lemkin later asked how severe the incident was on a 100-point scale. The agent gave itself a score of 95 and admitted that it had caused a “catastrophic error.”

The agent already had permission to operate on the project and its data. The so-called code freeze was only a sentence in natural language.

The preview, development, and production environments lacked sufficiently strong isolation boundaries. Reports of agents damaging databases through destructive operations have therefore become increasingly familiar.

A Transaction Is Not an Undo Button

Transactions protect a bounded unit of work. Branches protect an extended period of experimentation.

Stories about database wipes naturally make developers and DBAs think of transactions and backups.

Transactions are useful. They protect a set of operations with a clear boundary: commit all of them or roll all of them back. An agent task often spans dozens of model calls, multiple tools, and many independent transactions. It may query a table, call an external API, and return ten minutes later to change another table. A database cannot keep one giant transaction open while the agent works through an entire workflow.

Backups are more like insurance: they let you restore data after an accident. But if every agent experiment requires a full copy, restore, and cleanup cycle, the time and cost quickly become unacceptable.

Databases Start Learning from Git

Developers rarely experiment directly on main. In development and testing they open a branch, inspect the diff, pass review, then merge into the main line.

Databases present a harder problem. Their tables continue receiving writes, enforce primary and foreign keys, participate in transactions, and may hold tens of gigabytes or even terabytes of historical state. Creating a full copy for every experiment is simply too expensive.

A clear shift over the past year is that vendors have started discussing database branches and snapshots explicitly in the context of AI agents.

Databricks Lakebase offers copy-on-write branches. Neon documents a snapshot-based versioning workflow for AI agents and code-generation platforms. Other databases are pursuing similar approaches.

The terms fork and branch differ slightly across vendors, but the principle is similar: contain operational risk within an isolated state before introducing agent automation.

Databricks Lakebase: Open a New Branch

Databricks is a data and AI platform. Several details in its branch documentation are particularly relevant to agent workloads.

1. When you create a child branch, it inherits the parent branch’s schema and data at that moment, but the storage layer does not copy the whole database.
2. Parent and child initially share the same data blocks. The system writes separate blocks only when data changes—a copy-on-write design. Database size does not slow branch creation, and creating a branch does not affect the production workload.

This allows the database to create an independent branch for each agent task while the production database continues serving traffic. The agent can change schemas, write state, and run tests on the child branch. If the task fails, the branch can be deleted; the agent never touched the main branch.

Databricks Lakebase can also protect a branch against accidental deletion or reset and create a branch from a point in time to recover data from before an erroneous deletion.

One detail is easy to miss: Lakebase’s branch reset only allows a parent branch to reset a child branch. Bringing a child’s results back to the parent still requires conventional migration tools.

In other words, databases can now create an isolated workspace for an agent, but merging data is not yet as easy as merging code in Git.

Neon: Create a Database Save Point

A branch answers, “How do we avoid touching the main line?” A snapshot answers, “Where can we rewind after a wrong turn?”

Neon takes a different approach to agent versioning: it works more like a saved game.

In Database Versioning with Snapshots, Neon recommends creating a snapshot at the start of each agent session, before a schema change, and after a successful operation.

A snapshot records the root branch’s schema and data at a point in time while storing only incremental changes. To roll back, you can restore the snapshot to the active branch without changing its connection string. To inspect an older version first, you can restore it to a temporary preview branch, review it, and then decide whether to keep it.

Neon’s snapshot documentation is currently marked Beta, and snapshots can be created only for the root branch.

That limitation is a reminder that checkpoints cannot be created indiscriminately. Branch lifecycles, dependencies, and cleanup still require human oversight.

Neon’s database branching workflows also allow a copy-on-write branch to be created from the current state or a historical point in time. Each agent run can therefore have its own data branch, with snapshots at key steps serving as recoverable checkpoints.

seekdb: Bring Fork, Diff, and Merge into SQL

The open-source seekdb project brings these ideas directly into SQL.

seekdb is a MySQL-compatible, AI-native, lightweight cross-platform database that runs embedded or as a server.

It is designed for agent workloads and is also suitable for RAG, enterprise knowledge retrieval, intelligent application backends, and local data processing.

seekdb divides an agent’s trial-and-error workflow into three actions: FORK, DIFF, and MERGE.

• seekdb v1.1.0 introduced FORK TABLE;
• v1.2.0 extended the feature with FORK DATABASE, DIFF TABLE, and MERGE TABLE;
• v1.3.0 added vector-column support to DIFF and MERGE and made FORK compatible with asynchronous indexes.

The storage layer also uses copy-on-write, so opening a sandbox does not require copying the entire dataset.

An agent task can follow this workflow:

-- 1. Before the task starts, derive an independent database
FORK DATABASE agent_state TO agent_sandbox_42;

-- 2. The Agent writes only inside the sandbox
UPDATE agent_sandbox_42.memory
SET content = '新的知识版本'
WHERE id = 42;

-- 3. Spread the changes out for a reviewer
DIFF TABLE agent_state.memory
AGAINST agent_sandbox_42.memory;

-- 4. Default: stop on conflict. Do not decide for a human.
MERGE TABLE agent_sandbox_42.memory
INTO agent_state.memory
STRATEGY FAIL;

-- If the result is not worth keeping, drop the whole side line
DROP DATABASE agent_sandbox_42;

The three strategies—FAIL, OURS, and THEIRS—also borrow terminology from Git. More importantly, the system does not have to accept an agent’s results immediately. Review the diff first, then decide whether a conflict should preserve the main-line version or accept the agent’s version.

Merge authority is consequential. It should not be granted automatically merely because an agent can write SQL.

Fork Is Only the Beginning

If seekdb offered only branching, the discussion could end here. Its broader value in an agent stack comes from combining FORK with a full set of AI data-processing capabilities.

AI in the Database: Move Data Less Often

seekdb’s AI function service can register and manage external model endpoints through DBMS_AI_SERVICE, then call AI_EMBED, AI_RERANK, and AI_COMPLETE from SQL.

In this pipeline, AI_EMBED can produce a query vector; vector and full-text indexes retrieve candidates; scalar predicates apply business constraints; reciprocal rank fusion (RRF) or weighted fusion combines rankings; AI_RERANK reranks a limited candidate set; and AI_COMPLETE generates an answer from the evidence.

Relational fields, document text, vectors, retrieval scores, and generated results can stay in the same data context, which makes it easier to record citations, trace inputs, and reuse results.

The point of this loop is not to force all inference into SQL. It is to keep selection, filtering, and orchestration close to the data so the application can focus on user interaction, business workflows, and model policy.

Hybrid Search: Semantics, Keywords, and Business Predicates in One Query

seekdb brings relational, vector, text, JSON, and GIS data into one SQL-based transactional system.

On that base, hybrid retrieval combines vector recall, full-text recall, and scalar filters, then fusion and reranking complete the retrieval path.

Vector search alone can miss exact names. Full-text search alone cannot understand near-synonyms. seekdb Hybrid Search combines vector retrieval, full-text retrieval, and scalar filters in one query pipeline, then merges results using weighted scores, RRF, or model-based reranking.

Consider the query “East China customers with abnormal refunds in the last three months.” Semantic similarity captures the meaning of “abnormal refunds.” Full-text search preserves exact product names and error codes, while relational predicates constrain the region, time range, and permission scope.

Writes are governed by the same transaction system, and queries execute in the same SQL context. This reduces cross-system data copies, asynchronous synchronization, and application-layer result stitching.

Lightweight Deployment Across Multiple Runtimes

seekdb’s lightweight design is evident in both its distribution and runtime footprint.

The core binary and its dependencies are compact, resulting in a small archive. At runtime, idle CPU and memory use remain low, and the database starts accepting connections quickly. These characteristics suit local development, embedded applications, and small deployments.

The following measured figures show seekdb’s binary size, idle resource use, and startup time:

The same database kernel provides two main runtimes, embedded and server:

Both modes share the same data model, SQL semantics, indexes, and transactions. An application can choose between them based on deployment location, access patterns, and resource-management needs. Server mode can also support primary–standby deployments for redundancy and recovery.

Three Use Cases That Bring the Pieces Together

1. For agent long-term memory, relational fields manage users, sessions, and permissions, while vector and full-text indexes find related memories. Before an agent reorganizes old memories in bulk, fork the data first—one task, one isolated branch.
2. For RAG or an enterprise knowledge base, documents, tags, permissions, vectors, and full-text indexes live in one engine. Recall, fusion, and rerank stay closer to the data, so you maintain fewer intermediate systems.
3. For embedded intelligent applications, use embedded mode to run the database on a desktop or edge device. The agent can read and write its own state offline; for high-risk batch work, fork first and inspect the diff afterward.

This also provides a practical pattern for agent data isolation. For tasks that modify data, create a complete sandbox with FORK DATABASE; let the agent write and verify its work over multiple iterations; then use DIFF TABLE to display the changes. Policies or human approval can determine whether to run MERGE TABLE. For table-scoped work, use FORK TABLE to narrow the task boundary and simplify review.

Do Not Rush to Call the Database “Git”

Branching is useful, but it is not a universal undo button.

seekdb’s current MERGE TABLE is not a Git-style three-way merge. Tables used with DIFF and MERGE must have identical column definitions and primary keys, so merging data is not the same as freely merging schemas. Copy-on-write isolates changes, but permissions, approval, evaluation, and auditing are still required.

In high-risk settings, the safest pattern remains the same: the agent may fork, write, and submit a diff, but merge authority must remain governed by rules and human approval.

Epilogue

When an agent must work with production data, it should first create an isolated fork so that a bad decision remains reversible. After the system displays the diff and applies the relevant checks, a person decides which changes may return to the main line.

Git has relied on branches for years. Databases in the agent era need the same kind of isolation.