Your agent can't sign up for a database. We fixed that.

Here's what it looks like when an AI agent provisions its own database:

Read https://d0.seekdb.ai/SKILL.md and follow the instructions to create a database.

Five seconds later, it has a MySQL-compatible instance with vector search, full-text search, and native data branching. No signup, no credit card, no config.

For humans, same thing, one line:

eval "$(curl -s -X POST 'https://d0.seekdb.ai/api/v1/instances?format=shell')"

seekdb D0 is a free, 7-day trial layer built for AI agents on top of seekdb, an open-source AI-native search database. No signup form, no console, no human in the loop — the agent reads a URL, gets a database, and starts working. This post answers the questions you'd ask next.

How is this different from Neon / Supabase / Dolt?

Each tool makes different trade-offs:

• Neon is the most mature serverless Postgres — excellent branching, strong ecosystem, battle-tested in production. Trade-off: account required, no data diff/merge across branches.
• Supabase gives you a full backend (auth, storage, edge functions) on top of Postgres. Trade-off: branching is heavyweight (full instance spin-up), schema-only by default.
• Dolt has the strongest Git-for-data semantics — proper three-way merge, full version history. Trade-off: no vector search, no serverless hosting, local install required.
• seekdb D0 trades ecosystem maturity for a specific combination: MySQL protocol + vector/full-text/hybrid search + COW branching with diff/merge + zero-signup provisioning. Trade-off: younger project, 7-day trial only, smaller community.

If you're building on Postgres and need production-grade branching, Neon is probably your best bet. If you need full Git semantics for data versioning, Dolt is purpose-built for that. seekdb D0 occupies a different niche: the agent that needs a search-capable, branch-aware MySQL database right now, with no signup flow in the way.

Why MySQL, not Postgres?

Two reasons — one practical, one architectural.

Practically, current LLMs generate MySQL syntax more often than Postgres when prototyping applications. MySQL drivers tend to be lighter (PyMySQL is pure Python, zero native deps), and connection setup has fewer moving parts (no sslmode negotiation). For an agent spinning up a throwaway database, this reduces the surface area for errors.

Architecturally, seekdb is built on the OceanBase storage engine, which speaks the MySQL protocol natively — it's not a compatibility layer or a shim. PyMySQL, mysql2, JDBC, any MySQL driver connects directly.

That said, Postgres has a richer extension ecosystem (pgvector, PostGIS, pg_trgm) and a larger share of production deployments. If your agent stack is already Postgres-native, Neon or Supabase will fit more naturally. seekdb D0 is a better fit when your agent generates MySQL, or when you need vector + full-text + branching without assembling multiple extensions.

What can it actually do?

seekdb packs three search modes into one engine, and seekdb D0 exposes all of them.

Vector search — approximate nearest neighbor, standard SQL:

CREATE TABLE docs (
    id INT PRIMARY KEY AUTO_INCREMENT,
    content TEXT,
    embedding VECTOR(768),
    VECTOR INDEX idx_emb(embedding) WITH (distance=cosine, type=ivf_flat)
);

SELECT id, content, cosine_distance(embedding, '[0.12, 0.34, ...]') AS score
FROM docs ORDER BY score APPROXIMATE LIMIT 10;

Full-text search — multiple tokenizers (Space, Ngram, IK for Chinese, jieba for multilingual):

CREATE FULLTEXT INDEX ft_idx ON docs(content);

SELECT id, MATCH(content) AGAINST('refund policy') AS score
FROM docs WHERE MATCH(content) AGAINST('refund policy')
ORDER BY score DESC LIMIT 10;

Hybrid search — vector + keyword in a single query:

SET @p = '{
    "query": {"query_string": {"fields": ["content"], "query": "refund policy", "boost": 2.0}},
    "knn":   {"field": "embedding", "k": 10, "query_vector": [0.12, 0.34, ...], "boost": 1.0}
}';
SELECT JSON_PRETTY(DBMS_HYBRID_SEARCH.SEARCH('docs', @p));

One query, one transaction, one result set. No application-layer merge of results from separate vector and keyword systems. Details in the seekdb-search skill.

Show me the branching

Three SQL statements. That's it.

-- 1. Fork: instant clone, copy-on-write, milliseconds regardless of data size
FORK TABLE knowledge_base TO kb_branch;

-- 2. Diff: see exactly what the agent changed
DIFF TABLE knowledge_base AGAINST kb_branch;

-- 3. Merge: apply the changes (strategies: FAIL, THEIRS, OURS)
MERGE TABLE kb_branch INTO knowledge_base STRATEGY THEIRS;

The agent experiments freely on the branch. The main table is untouched until you explicitly merge. If the branch is garbage, drop it. This is Git for your data — pull request workflow, applied to tables.

Instance-level fork (clone the entire database) is one API call:

eval "$(curl -s -X POST \
  'https://d0.seekdb.ai/api/v1/instances/'$D0_INSTANCE_ID'/fork?format=shell' \
  -H 'Content-Type: application/json' \
  -d "{\"password\": \"$D0_PASSWORD\"}")"

Milliseconds. New credentials, new TTL, fully independent.

Why is FORK so fast? seekdb runs on an LSM-Tree storage engine. Data is append-only, so historical versions are naturally preserved. FORK just records the current log sequence number as a branch point — no data is copied. The new branch shares all existing files; new files are only created on write. Cost is constant: a 100GB database forks as fast as a 1MB one.

Full workflow details in the seekdb-branch skill.

How do agents know how to use this?

seekdb D0 exposes a machine-readable file at d0.seekdb.ai/SKILL.md — instance creation, connection parameters, SQL examples, fork workflow, search capabilities, all in one document. Any LLM that can read text can follow it. No MCP plugin, no SDK, no special client library.

Read https://d0.seekdb.ai/SKILL.md and follow the instructions to create a database using seekdb D0.

That single prompt is enough for Claude, GPT-4, Gemini, or any capable agent to provision a database, connect, create tables, run queries, fork, diff, and merge — all autonomously.

No MySQL driver in the environment? seekdb D0 also has an HTTP Query API:

curl -s -X POST https://d0.seekdb.ai/api/v1/query \
  -H 'Content-Type: application/json' \
  -d '{"instance_id":"'$D0_INSTANCE_ID'","password":"'$D0_PASSWORD'","sql":"SELECT NOW()"}'

What's the catch?

seekdb D0 is a 7-day playground for agent. Designed for prototyping, evaluation, demos, and experimentation.

• 7-day TTL — instances auto-delete after expiry
• Resource caps — per-instance compute and storage limits
• No AI functions — AI_EMBED, AI_COMPLETE disabled in trial instances
• No SLA — it's a free service, not a production platform
• Max 5 instances per fork lineage

For production: self-host seekdb (Apache-2.0, full capabilities, no restrictions) or talk to the OceanBase team about managed options.

Try It

Read https://d0.seekdb.ai/SKILL.md and follow the instructions to create a database using seekdb D0.

Send that to your agent, or run this yourself:

eval "$(curl -s -X POST 'https://d0.seekdb.ai/api/v1/instances?format=shell')"
mysql $D0_CONNECTION

Seven days, zero signup. If it works for your use case:

• Self-host: github.com/oceanbase/seekdb — Apache-2.0, full capabilities, no restrictions
• Managed service: reach out to the OceanBase team for cloud deployment, scale, and support

Links

• seekdb D0: d0.seekdb.ai
• Branch workflow: seekdb-branch skill
• Search guide: seekdb-search skill
• seekdb GitHub: github.com/oceanbase/seekdb

Author:
- Kun Fan, Software Engineer of seekdb
- Matthew Bian, Software Engineer of seekdb D0