TiDB Cloud Zero public preview. Disposable MySQL-compatible databases for agents, demos, and search-heavy apps.
AI Agent Memory

AI Agent Memory Database

Agent memory is not only embeddings. Real agents also need structured state, tool outputs, user preferences, traces, and exact lookups. TiDB Cloud Zero gives you a disposable MySQL-compatible database that can hold relational data, vector data, and text search in one place.

Provision with one unauthenticated HTTPS call. Store relational state, embeddings, and searchable text together. Use it for prototypes, eval runs, and per-session agent sandboxes. Claim the instance later if the temporary database needs to live on.
Home / Use Cases / AI Agent Memory Database

Why agent memory needs more than a vector store

Long-term memory for agents usually mixes exact facts with fuzzy recall. User profiles, task state, tool results, and audit trails fit naturally in SQL tables, while semantic retrieval benefits from vector search.

TiDB Cloud Zero is useful when you want both patterns in the same backend instead of stitching together a separate vector store, cache, and relational database before the idea is even proven.

  • Session memory and user preferences
  • Tool invocation logs and structured state
  • Semantic lookup over embeddings
  • Text lookup over notes, prompts, or transcripts

Where TiDB Cloud Zero fits

Zero is a good fit for early agent products, reproducible demos, and evaluation runs where spinning up infrastructure should not block the experiment.

It is intentionally disposable. If the workflow graduates from prototype to persistent product data, the claim flow moves the database into a regular TiDB Cloud Starter environment.

What people actually search for

This page is designed for queries like AI agent memory, SQL memory store, long-term memory for AI agents, and agent state database. The common thread is simple: teams want a real database, not another mock store, but they do not want operational overhead on day one.

Create a disposable SQL memory backend

This example keeps the flow simple: create a database, export the connection string, and start using it with standard MySQL tooling.

curl -s -X POST https://zero.tidbapi.com/v1beta1/instances \
  -H "Content-Type: application/json" \
  -d '{"tag":"agent-memory"}' \
  | tee tidb-zero.json

export TIDB_CONNECTION_STRING="$(jq -r '.instance.connectionString' tidb-zero.json)"

mysql "$TIDB_CONNECTION_STRING" -e "
CREATE TABLE IF NOT EXISTS agent_memory (
  memory_id BIGINT PRIMARY KEY AUTO_INCREMENT,
  agent_id VARCHAR(64) NOT NULL,
  memory_type VARCHAR(32) NOT NULL,
  content TEXT NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);"

Related Paths

Keep the site graph tight. Each page answers a different question and links to the next most relevant topic.

FAQ

Can TiDB Cloud Zero be used for long-term agent memory?
It can be used to prototype long-term memory patterns, especially when you need SQL state plus retrieval in one place. For production persistence, claim the database into TiDB Cloud before the temporary session expires.
Does agent memory have to be vector-only?
No. Many agent memory workloads need exact filters, joins, user state, and auditability alongside semantic recall. That is why a MySQL-compatible database can be a better fit than a vector-only backend.
Which frameworks can connect to it?
Any framework or custom agent runtime that can talk to a MySQL-compatible database over TLS can use TiDB Cloud Zero.